Gerir pontos finais do Microsoft 365

A maioria das organizações empresariais que têm várias localizações de escritório e uma WAN de ligação precisam de configuração para a conectividade de rede do Microsoft 365. Pode otimizar a sua rede ao enviar todos os pedidos de rede fidedignos do Microsoft 365 diretamente através da firewall, ignorando toda a inspeção ou processamento adicional ao nível do pacote. Isto reduz a latência e os requisitos de capacidade de perímetro. Identificar o tráfego de rede do Microsoft 365 é o primeiro passo para proporcionar um desempenho ideal aos seus utilizadores. Para obter mais informações, veja Princípios de Conectividade de Rede do Microsoft 365.

A Microsoft recomenda que aceda aos pontos finais de rede do Microsoft 365 e às alterações contínuas aos mesmos através do Serviço Web de URL e Endereço IP do Microsoft 365.

Independentemente da forma como gere o tráfego de rede vital do Microsoft 365, o Microsoft 365 requer conectividade à Internet. Outros pontos finais de rede onde a conectividade é necessária estão listados em Pontos finais adicionais não incluídos no Serviço Web de URL e Endereço IP do Microsoft 365.

A forma como utiliza os pontos finais de rede do Microsoft 365 depende da arquitetura de rede da sua organização empresarial. Este artigo descreve várias formas de integração de arquiteturas de rede empresarial com endereços IP e URLs do Microsoft 365. A forma mais fácil de escolher que pedidos de rede confiar é utilizar dispositivos SD-WAN que suportam a configuração automatizada do Microsoft 365 em cada uma das suas localizações do escritório.

SD-WAN para saída de ramo local do tráfego de rede vital do Microsoft 365

Em cada localização da sucursal, pode fornecer um dispositivo SD-WAN configurado para encaminhar o tráfego para a categoria de pontos finais Otimizar do Microsoft 365 ou Otimizar e Permitir categorias diretamente para a rede da Microsoft. Outro tráfego de rede, incluindo tráfego de datacenter no local, tráfego geral de sites da Internet e tráfego para pontos finais de categoria predefinidos do Microsoft 365 é enviado para outra localização onde tem um perímetro de rede mais substancial.

A Microsoft está a trabalhar com fornecedores de SD-WAN para ativar a configuração automatizada. Para obter mais informações, consulte Microsoft 365 Programa de Parceiros de Redes.

Utilizar um ficheiro PAC para encaminhamento direto de tráfego vital do Microsoft 365

Utilize ficheiros PAC ou WPAD para gerir pedidos de rede associados ao Microsoft 365, mas que não têm um endereço IP. Os pedidos de rede típicos enviados através de um proxy ou dispositivo de perímetro aumentam a latência. Enquanto a Interrupção do TLS e a Inspeção criam a maior latência, outros serviços, como a autenticação de proxy e a pesquisa de reputação, podem causar um mau desempenho e uma má experiência de utilizador. Além disso, estes dispositivos de rede de perímetro precisam de capacidade suficiente para processar todos os pedidos de ligação de rede. Recomendamos que ignore os seus dispositivos de proxy ou inspeção para pedidos de rede diretos do Microsoft 365.

Galeria do PowerShell Get-PacFile é um script do PowerShell que lê os pontos finais de rede mais recentes do serviço Web de Endereços IP e URL do Microsoft 365 e cria um ficheiro PAC de exemplo. Pode modificar o script para que se integre na gestão de ficheiros PAC existente.

Nota

Para obter mais informações sobre as considerações de segurança e desempenho da conectividade direta aos pontos finais do Microsoft 365, consulte Princípios de Conectividade de Rede do Microsoft 365.

Figura 1 - Perímetro de rede empresarial simples

O ficheiro PAC é implementado em browsers no ponto 1 na Figura 1. Ao utilizar um ficheiro PAC para uma saída direta do tráfego de rede vital do Microsoft 365, também tem de permitir a conectividade aos endereços IP por trás destes URLs na firewall de perímetro de rede. Isto é feito ao obter os endereços IP para as mesmas categorias de ponto final do Microsoft 365, conforme especificado no ficheiro PAC e ao criar ACLs de firewall com base nesses endereços. A firewall é o ponto 3 na Figura 1.

Separadamente, se optar por efetuar apenas o encaminhamento direto para os pontos finais da categoria Otimizar, todos os pontos finais da categoria Permitir necessários que envie para o servidor proxy têm de ser listados no servidor proxy para ignorar o processamento adicional. Por exemplo, a quebra TLS e a Inspeção e a Autenticação de Proxy são incompatíveis com os pontos finais de categoria Otimizar e Permitir. O servidor proxy é o ponto 2 na Figura 1.

A configuração comum é permitir sem processar todo o tráfego de saída do servidor proxy para os endereços IP de destino para o tráfego de rede do Microsoft 365 que atinge o servidor proxy. Para obter informações sobre problemas com a Interrupção do TLS e a Inspeção, consulte Utilizar dispositivos ou soluções de rede de terceiros no tráfego do Microsoft 365.

Existem dois tipos de ficheiros PAC que o script Get-PacFile gera.

Tipo	Descrição
1	Envie Otimizar o tráfego de ponto final direto e tudo o resto para o servidor proxy.
2	Envie Otimizar e Permitir tráfego de ponto final direto e tudo o resto para o servidor proxy. Este tipo também pode ser utilizado para enviar todo o ExpressRoute suportado para o tráfego do Microsoft 365 para segmentos de rede do ExpressRoute e tudo o resto para o servidor proxy.

Eis um exemplo simples de chamar o script do PowerShell:

Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

Existem muitos parâmetros que pode transmitir para o script:

Parâmetro	Descrição
ClientRequestId	Isto é necessário e é um GUID transmitido para o serviço Web que representa o computador cliente que faz a chamada.
Instância	A instância de serviço do Microsoft 365, que é predefinida como Global. Isto também é transmitido para o serviço Web.
TenantName	O seu nome de inquilino do Microsoft 365. Transmitido para o serviço Web e utilizado como parâmetro substituível em alguns URLs do Microsoft 365.
Tipo	O tipo do ficheiro PAC de proxy que pretende gerar.

Eis outro exemplo de como chamar o script do PowerShell com mais parâmetros:

Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

O servidor proxy ignora o processamento do tráfego de rede do Microsoft 365

Quando os ficheiros PAC não são utilizados para o tráfego de saída direto, continua a querer ignorar o processamento no perímetro da rede ao configurar o servidor proxy. Alguns fornecedores de servidores proxy ativaram a configuração automatizada, conforme descrito no microsoft 365 Programa de Parceiros de Redes.

Se o fizer manualmente, terá de obter os dados da categoria Otimizar e Permitir ponto final do Serviço Web de Endereços IP e URL do Microsoft 365 e configurar o servidor proxy para ignorar o processamento. É importante evitar a Interrupção do TLS e Inspecionar e Autenticação de Proxy para os pontos finais da categoria Otimizar e Permitir.

Gestão de alterações para endereços IP e URLs do Microsoft 365

Além de selecionar a configuração adequada para o perímetro de rede, é fundamental que adote um processo de gestão de alterações para pontos finais do Microsoft 365. Estes pontos finais mudam regularmente. Se não gerir as alterações, pode acabar com os utilizadores bloqueados ou com fraco desempenho após a adição de um novo endereço IP ou URL.

Normalmente, as alterações aos endereços IP e URLs do Microsoft 365 são publicadas perto do último dia de cada mês. Por vezes, uma alteração é publicada fora desse agendamento devido a requisitos operacionais, de suporte ou de segurança.

Quando é publicada uma alteração que exige que aja porque foi adicionado um endereço IP ou URL, deverá receber um aviso prévio de 30 dias a partir do momento em que publicarmos a alteração até existir um serviço do Microsoft 365 nesse ponto final. Isto reflete-se como a Data Efetiva. Embora tenhamos como objetivo este período de notificação, poderá nem sempre ser possível devido a requisitos operacionais, de suporte ou de segurança. As alterações que não requerem uma ação imediata para manter a conectividade, como endereços IP ou URLs removidos ou alterações menos significativas, não incluem notificação antecipada. Nestes casos, não é fornecida nenhuma Data Efetiva. Independentemente da notificação fornecida, apresentamos a data de atividade do serviço esperada para cada alteração.

Alterar notificação com o Serviço Web

Pode utilizar o Endereço IP e o Serviço Web de URL do Microsoft 365 para receber a notificação de alteração. Recomendamos que chame o método Web /version uma vez por hora para verificar a versão dos pontos finais que está a utilizar para ligar ao Microsoft 365. Se esta versão for alterada em comparação com a versão que tem em utilização, deverá obter os dados de ponto final mais recentes a partir do método Web /endpoints e, opcionalmente, obter as diferenças do método Web /changes . Não é necessário chamar os métodos Web /endpoints ou /changes se não tiver havido qualquer alteração à versão que encontrou.

Para obter mais informações, veja Endereço IP e Serviço Web de URL do Microsoft 365.

Alterar a notificação com feeds RSS

O Endereço IP e o Serviço Web de URL do Microsoft 365 fornecem um feed RSS que pode subscrever no Outlook. Existem ligações para os URLs de RSS em cada uma das páginas específicas da instância de serviço do Microsoft 365 para os endereços IP e URLs. Para obter mais informações, veja Endereço IP e Serviço Web de URL do Microsoft 365.

Alterar a notificação e a revisão de aprovação com o Power Automate

Compreendemos que ainda poderá necessitar de processamento manual para alterações de pontos finais de rede que surgem todos os meses. Pode utilizar o Power Automate para criar um fluxo que o notifica por e-mail e, opcionalmente, executa um processo de aprovação para alterações quando os pontos finais de rede do Microsoft 365 têm alterações. Assim que a revisão estiver concluída, pode fazer com que o fluxo envie automaticamente as alterações por e-mail para a sua equipa de gestão de servidores proxy e firewall.

Para obter informações sobre um exemplo e modelo do Power Automate, veja Utilizar o Power Automate para receber um e-mail para obter alterações a endereços IP e URLs do Microsoft 365.

FAQ sobre pontos finais de rede do Microsoft 365

Veja estas perguntas mais frequentes sobre a conectividade de rede do Microsoft 365.

Como devo proceder para submeter uma pergunta?

Selecione a ligação na parte inferior para indicar se o artigo foi útil ou não e submeta mais perguntas. Monitorizamos o feedback e atualizamos as perguntas aqui com as perguntas mais frequentes.

Como devo proceder para determinar a localização do meu inquilino?

A localização do inquilino é melhor determinada com o nosso mapa do datacenter.

Estou a criar um peering adequado com a Microsoft?

As localizações de peering são descritas mais detalhadamente no peering com a Microsoft.

Com mais de 2500 relações de peering do ISP globalmente e 70 pontos de presença, passar da sua rede para a nossa deve ser totalmente integrado. Não faz mal passar alguns minutos a certificar-se de que a relação de peering do SEU ISP é a mais ideal. Seguem-se alguns exemplos de boas e não tão boas transferências de peering para a nossa rede.

Vejo pedidos de rede para endereços IP que não estão na lista publicada. Preciso de lhes conceder acesso?

Apenas fornecemos endereços IP para os servidores do Microsoft 365 para os quais deve encaminhar diretamente. Esta não é uma lista abrangente de todos os endereços IP para os quais verá pedidos de rede. Verá pedidos de rede à Microsoft e endereços IP de terceiros, não publicados. Estes endereços IP são gerados ou geridos dinamicamente de uma forma que impede o aviso oportuno quando são alterados. Se a firewall não puder permitir o acesso com base nos FQDNs para estes pedidos de rede, utilize um ficheiro PAC ou WPAD para gerir os pedidos.

Consulte um IP associado ao Microsoft 365 sobre o qual pretende obter mais informações?

1. Verifique se o endereço IP está incluído num intervalo publicado maior com uma calculadora CIDR, como as de IPv4 ou IPv6. Por exemplo, 40.96.0.0/13 inclui o Endereço IP 40.103.0.1, apesar de 40,96 não corresponder a 40,103.
2. Veja se um parceiro é o proprietário do IP com uma consulta whois. Se for propriedade da Microsoft, poderá ser um parceiro interno. Muitos pontos finais de rede de parceiros estão listados como pertencentes à categoria predefinida , para a qual os endereços IP não são publicados.
3. O endereço IP pode não fazer parte do Microsoft 365 ou de uma dependência. A publicação de pontos finais de rede do Microsoft 365 não inclui todos os pontos finais de rede da Microsoft.
4. Verifique o certificado. Com um browser, ligue-se ao endereço IP com https://<IP_address> e verifique os domínios listados no certificado para compreender que domínios estão associados ao endereço IP. Se for um endereço IP da Microsoft e não estiver na lista de endereços IP do Microsoft 365, é provável que o endereço IP esteja associado a uma CDN da Microsoft, como MSOCDN.NET ou outro domínio da Microsoft sem informações de IP publicadas. Se encontrar o domínio no certificado é aquele em que afirmamos listar o endereço IP, informe-nos.

Alguns URLs do Microsoft 365 apontam para registos CNAME em vez de registos A no DNS. O que tenho a ver com os registos CNAME?

Os computadores cliente precisam de um registo DNS A ou AAAA que inclua um ou mais endereços IP para ligar a um serviço cloud. Alguns URLs incluídos no Microsoft 365 mostram registos CNAME em vez de registos A ou AAAA. Estes registos CNAME são intermediários e podem existir vários numa cadeia. Serão sempre resolvidos para um registo A ou AAAA para um Endereço IP. Por exemplo, considere a seguinte série de registos DNS, que, em última análise, resolvem para o endereço IP IP_1:

serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1

Estes redirecionamentos CNAME são uma parte normal do DNS e são transparentes para o computador cliente e transparentes para os servidores proxy. São utilizados para balanceamento de carga, redes de entrega de conteúdos, elevada disponibilidade e mitigação de incidentes de serviço. A Microsoft não publica os registos CNAME intermediários, estão sujeitos a alterações em qualquer altura e não deve ter de os configurar conforme permitido no servidor proxy.

Um servidor proxy valida o URL inicial, que no exemplo acima é serviceA.office.com e este URL seria incluído na publicação do Microsoft 365. O servidor proxy pede a resolução de DNS desse URL para um Endereço IP e recebe novamente IP_1. Não valida os registos de redirecionamento CNAME intermediários.

As configurações hard-coded ou a utilização de uma lista de permissões baseada em FQDNs indiretos do Microsoft 365 não são recomendadas e não são suportadas pela Microsoft. Sabe-se que causam problemas de conectividade do cliente. As soluções DNS que bloqueiam o redirecionamento CNAME ou que resolvem incorretamente as entradas DNS do Microsoft 365 podem ser resolvidas através de reencaminhadores DNS com a recursão DNS ativada ou através de sugestões de raiz DNS. Muitos produtos de perímetro de rede de terceiros integram nativamente o ponto final recomendado do Microsoft 365 para incluir uma lista de permissões na respetiva configuração através do Serviço Web de URL e Endereço IP do Microsoft 365.

Por que motivo vejo nomes como nsatc.net ou akadns.net nos nomes de domínio da Microsoft?

O Microsoft 365 e outros serviços Microsoft utilizam vários serviços de terceiros, como o Akamai e o MarkMonitor, para melhorar a sua experiência do Microsoft 365. Para continuar a dar-lhe a melhor experiência possível, poderemos alterar estes serviços no futuro. Os domínios de terceiros podem alojar conteúdo, como uma CDN, ou podem alojar um serviço, como um serviço de gestão de tráfego geográfico. Alguns dos serviços atualmente em utilização incluem:

O MarkMonitor está a ser utilizado quando vê pedidos que incluem *.nsatc.net. Este serviço fornece proteção e monitorização de nomes de domínio para proteger contra comportamentos maliciosos.

ExactTarget está a ser utilizado quando vê pedidos para *.exacttarget.com. Este serviço fornece gestão de ligações de e-mail e monitorização contra comportamentos maliciosos.

O Akamai está a ser utilizado quando vê pedidos que incluem um dos seguintes FQDNs. Este serviço oferece serviços de rede de entrega de conteúdos e DNS geográficos.

*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net

Tenho de ter a conectividade mínima possível para o Microsoft 365

Uma vez que o Microsoft 365 é um conjunto de serviços criados para funcionar através da Internet, as promessas de fiabilidade e disponibilidade baseiam-se em muitos serviços de Internet padrão disponíveis. Por exemplo, os serviços de Internet padrão, como DNS, CRL e CDNs, têm de estar acessíveis para utilizar o Microsoft 365, tal como têm de estar acessíveis para utilizar a maioria dos serviços de Internet modernos.

O conjunto de aplicações do Microsoft 365 está dividido em quatro áreas de serviço principais que representam as três cargas de trabalho principais e um conjunto de recursos comuns. Estas áreas de serviço podem ser utilizadas para associar fluxos de tráfego a uma determinada aplicação. No entanto, dado que as funcionalidades consomem frequentemente pontos finais em várias cargas de trabalho, estas áreas de serviço não podem ser utilizadas de forma eficaz para restringir o acesso.

Área de Serviço	Descrição
Exchange	Exchange Online e Proteção do Exchange Online
SharePoint	SharePoint Online e OneDrive for Business
Skype para Empresas Online e Microsoft Teams	Skype para Empresas e Microsoft Teams
Comum	Microsoft 365 Pro Plus, Office num browser, Microsoft Entra ID e outros pontos finais de rede comuns

Além dos serviços básicos de Internet, existem serviços de terceiros que são utilizados apenas para integrar funcionalidades. Embora estes serviços sejam necessários para integração, são marcados como opcionais no artigo Pontos finais do Microsoft 365. Isto significa que a funcionalidade principal do serviço continua a funcionar se o ponto final não estiver acessível. Qualquer ponto final de rede necessário tem o atributo necessário definido como verdadeiro. Qualquer ponto final de rede opcional tem o atributo necessário definido como falso e o atributo notas detalha a funcionalidade em falta que deve esperar se a conectividade estiver bloqueada.

Se estiver a tentar utilizar o Microsoft 365 e encontrar serviços de terceiros que não estão acessíveis, quer garantir que todos os FQDNs marcados como obrigatórios ou opcionais neste artigo são permitidos através do proxy e da firewall.

Como devo proceder para bloquear o acesso aos serviços de consumidor da Microsoft?

A funcionalidade de restrições de inquilino suporta agora o bloqueio da utilização de todas as aplicações de consumidor da Microsoft (aplicações MSA), como o OneDrive, Hotmail e Xbox.com. Esta funcionalidade utiliza um cabeçalho separado para o ponto final login.live.com. Para obter mais informações, veja Utilizar restrições de inquilinos para gerir o acesso a aplicações na cloud SaaS.

A minha firewall requer Endereços IP e não consegue processar URLs. Como devo proceder para configurá-lo para o Microsoft 365?

O Microsoft 365 não fornece endereços IP de todos os pontos finais de rede necessários. Alguns são fornecidos apenas como URLs e são categorizados como predefinidos. Os URLs na categoria predefinida necessária devem ser permitidos através de um servidor proxy. Se não tiver um servidor proxy, veja como configurou pedidos Web para URLs que os utilizadores escrevem na barra de endereço de um browser; o utilizador também não fornece um endereço IP. Os URLs de categoria predefinidos do Microsoft 365 que não fornecem endereços IP devem ser configurados da mesma forma.

Artigos relacionados

Endereço IP do Microsoft 365 e Serviço Web URL

Intervalos de IP do Datacenter do Microsoft Azure

Microsoft Public IP Space

Requisitos de infraestrutura de rede para Microsoft Intune

Intervalos de URLs e endereços IP do Microsoft 365

Princípios de Conectividade de Rede do Microsoft 365