Funcionamento em rede (para a cloud)— Ponto de vista de um arquiteto

Artigo
07/16/2023

Neste artigo, Ed Fisher, Arquiteto de Conformidade & de Segurança da Microsoft, descreve como otimizar a sua rede para conectividade na cloud, evitando as armadilhas mais comuns.

Acerca do autor

Captura de ecrã da fotografia de Ed Fisher.

Atualmente, sou Especialista Técnico Principal na nossa equipa de Retalho e Bens de Consumo, concentrando-me na Conformidade do & de Segurança. Trabalhei com clientes que se mudaram para Office 365 nos últimos dez anos. Trabalhei com lojas mais pequenas com um punhado de locais para agências governamentais e empresas com milhões de utilizadores distribuídos pelo mundo, e muitos outros clientes no meio, com a maioria a ter dezenas de milhares de utilizadores, várias localizações em várias partes do mundo, a necessidade de um maior grau de segurança e uma multiplicidade de requisitos de conformidade. Ajudei centenas de empresas e milhões de utilizadores a mudarem-se para a cloud de forma segura e segura.

Com formação nos últimos 25 anos que inclui segurança, infraestrutura e engenharia de rede, e tendo transferido dois dos meus empregadores anteriores para Office 365 antes de me juntar à Microsoft, estive muitas vezes do seu lado da tabela e lembro-me de como é. Embora nenhum dos dois clientes seja sempre o mesmo, a maioria tem necessidades semelhantes e, ao consumir um serviço padronizado, como qualquer plataforma SaaS ou PaaS, as melhores abordagens tendem a ser as mesmas.

Não é a rede — é assim que está (mis) a utilizá-la!

Não importa quantas vezes aconteça, nunca deixa de me surpreender a forma como as equipas de segurança criativas e as equipas de rede tentam obter a forma como pensam que devem ligar-se aos serviços cloud da Microsoft. Há sempre alguma política de segurança, padrão de conformidade ou melhor forma de insistirem em utilizar, sem estarem dispostos a participar numa conversa sobre o que estão a tentar realizar, ou como existem formas melhores, mais fáceis, mais económicas e mais eficazes de o fazer.

Quando este tipo de coisa é escalado para mim, eu normalmente estou disposto a aceitar o desafio e guiá-los através dos procedimentos e dos porquês e levá-los para onde precisam estar. Mas se estou a ser completamente franco, tenho de partilhar isso às vezes quero deixá-los fazer o que quiserem, e voltar a dizer que te disse para quando finalmente admitirem que não funciona. Posso querer fazer isso às vezes, mas não quero. O que faço é tentar explicar tudo o que vou incluir neste post. Independentemente da sua função, se a sua organização quiser utilizar os serviços cloud da Microsoft, provavelmente existe alguma sabedoria no que se segue que o pode ajudar.

Princípios de orientação

Vamos começar com algumas regras básicas sobre o que estamos a fazer aqui. Estamos a discutir como ligar de forma segura aos serviços cloud para garantir a complexidade mínima e o desempenho máximo, mantendo a segurança real. Nada do que se segue é contrário a nada disso, mesmo que você, ou o seu cliente, não consiga utilizar o seu servidor proxy favorito para tudo.

Só porque podes, não quer dizer que devas: Ou parafrasear o Dr. Ian Malcolm do filme do Parque Jurássico"... Sim, sim, mas a sua equipa de segurança estava tão preocupada em saber se podiam ou não parar para pensar se deviam."
A segurança não significa complexidade: não é mais seguro só porque gasta mais dinheiro, encaminha por mais dispositivos ou clica em mais botões.
Office 365 é acedido através da Internet: mas isso não é a mesma coisa que Office 365 é a Internet. É um serviço SaaS gerido pela Microsoft e administrado por si. Ao contrário dos sites que visita na Internet, pode realmente espreitar atrás da cortina e pode aplicar os controlos de que precisa para cumprir as suas políticas e os seus padrões de conformidade, desde que compreenda que, embora possa cumprir os seus objetivos, poderá ter de os fazer de uma forma diferente.
Os pontos de estrangulamento são maus, as fugas localizadas são boas: todos querem sempre recuar todo o tráfego da Internet para todos os seus utilizadores para algum ponto central, normalmente para que possam monitorizá-lo e impor a política, mas muitas vezes porque é mais barato do que aprovisionar o acesso à Internet em todas as suas localizações, ou é assim que o fazem. Mas esses pontos de estrangulamento são exactamente isso... aponta onde o tráfego sufoca. Não há nada de errado em impedir os seus utilizadores de navegarem para o Instagram ou transmitirem vídeos de gatos, mas não tratem o tráfego da sua aplicação empresarial crítica para a missão da mesma forma.
Se o DNS não estiver satisfeito, não há nada de feliz: a rede mais bem concebida pode ser prejudicada pelo DNS pobre, quer seja através da repetição de pedidos para servidores noutras áreas do mundo ou da utilização dos servidores DNS do SEU ISP ou de outros servidores DNS públicos que colocam em cache as informações de resolução de DNS.
Só porque era assim que costumava fazê-lo, não significa que seja assim que deve fazê-lo agora: a tecnologia muda constantemente e Office 365 não é exceção. A aplicação de medidas de segurança desenvolvidas e implementadas para serviços no local ou para controlar a navegação na Web não vai fornecer o mesmo nível de garantia de segurança e pode ter um impacto negativo significativo no desempenho.
Office 365 foi construído para ser acedido através da Internet: é tudo em poucas palavras. Independentemente do que queira fazer entre os seus utilizadores e a sua periferia, o tráfego continua a passar pela Internet assim que sai da sua rede e antes de entrar na nossa. Mesmo que esteja a utilizar o Azure ExpressRoute para encaminhar algum tráfego sensível à latência da sua rede diretamente para o nosso, a conectividade à Internet é absolutamente necessária. Aceite-o. Não se infunda demasiado.

Onde muitas vezes são feitas más escolhas

Embora haja muitos lugares onde são tomadas más decisões em nome da segurança, estas são as que encontro mais frequentemente com os clientes. Muitas conversas de clientes envolvem tudo isto ao mesmo tempo.

Recursos insuficientes no edge

Muito poucos clientes estão a implementar ambientes de campo verde e têm anos de experiência na forma como os seus utilizadores trabalham e como é a saída da Internet. Quer os clientes tenham servidores proxy ou permitam acesso direto e simplesmente tráfego de saída NAT, fazem-no há anos e não consideram o quanto mais vão começar a bombear através da sua periferia à medida que movem aplicações tradicionalmente internas para a cloud.

A largura de banda é sempre uma preocupação, mas os dispositivos NAT podem não ter potência suficiente para lidar com o aumento da carga e podem começar a fechar prematuramente as ligações para libertar recursos. A maioria do software de cliente que se liga a Office 365 espera ligações persistentes e um utilizador que utiliza totalmente Office 365 pode ter 32 ou mais ligações simultâneas. Se o dispositivo NAT os deixar cair prematuramente, essas aplicações podem deixar de responder à medida que tentam utilizar as ligações que já não existem. Quando desistem e tentam estabelecer novas ligações, colocam ainda mais carga na sua engrenagem de rede.

Fuga localizada

Tudo o resto nesta lista resume-se a uma coisa: sair da sua rede e aceder à nossa o mais rapidamente possível. Fazer uma cópia de segurança do tráfego dos seus utilizadores para um ponto de saída central, especialmente quando esse ponto de saída está noutra região do que os utilizadores, introduz latência desnecessária e afeta a experiência do cliente e as velocidades de transferência. A Microsoft tem pontos de presença em todo o mundo com front-ends para todos os nossos serviços e peering estabelecidos com praticamente todos os principais ISP, pelo que encaminhar o tráfego dos seus utilizadores localmente garante que entra rapidamente na nossa rede com a latência mínima.

O tráfego de resolução DNS deve seguir o caminho de saída da Internet

Claro que, para um cliente encontrar qualquer ponto final, tem de utilizar o DNS. Os servidores DNS da Microsoft avaliam a origem dos pedidos DNS para garantir que devolvemos a resposta que está, em termos de Internet, mais próxima da origem do pedido. Certifique-se de que o DNS está configurado para que os pedidos de resolução de nomes saiam pelo mesmo caminho que o tráfego dos utilizadores, para que não lhes dê saída local, mas sim para um ponto final noutra região. Isto significa permitir que os servidores DNS locais "vão para a raiz" em vez de reencaminhar para servidores DNS em datacenters remotos. E watch serviços DNS públicos e privados, que podem colocar em cache resultados de uma parte do mundo e servi-los a pedidos de outras partes do mundo.

Para o proxy ou não para o proxy, esta é a questão

Uma das primeiras coisas a ter em conta é se as ligações dos utilizadores proxy ao Office 365. É fácil. não proxy. Office 365 é acedido através da Internet, mas não é a Internet. É uma extensão dos seus serviços principais e deve ser tratada como tal. Tudo o que pretender que um proxy faça, como DLP, antimalware ou inspeção de conteúdo, já está disponível no serviço e pode ser utilizado em escala e sem necessidade de detetar ligações encriptadas por TLS. No entanto, se realmente quiser utilizar o tráfego de proxy que de outra forma não pode controlar, preste atenção à nossa documentação de orientação em https://aka.ms/pnc e às categorias de tráfego em https://aka.ms/ipaddrs. Temos três categorias de tráfego para Office 365. A opção Otimizar e Permitir deve realmente ir diretamente e ignorar o proxy. A predefinição pode ser proxiada. Os detalhes estão nesses documentos... lê-los.

A maioria dos clientes que insistem em utilizar um proxy, quando realmente olham para o que estão a fazer, apercebem-se de que quando o cliente faz um pedido HTTP CONNECT ao proxy, o proxy é agora apenas um router extra caro. Os protocolos em utilização, como MAPI e RTC, nem sequer são protocolos que os proxies Web compreendem, pelo que, mesmo com o TLS a descodificação, não está realmente a obter segurança extra. Está a receber latência extra. Veja para obter https://aka.ms/pnc mais informações, incluindo as categorias Otimizar, Permitir e Predefinição para o tráfego do Microsoft 365.

Por fim, considere o impacto geral no proxy e a resposta correspondente para lidar com esse impacto. À medida que cada vez mais ligações são feitas através do proxy, pode diminuir o Fator de Dimensionamento TCP para que não tenha de colocar tanto tráfego na memória intermédia. Já vi clientes onde os proxies estavam tão sobrecarregados que estavam a usar um Factor de Escala de 0. Uma vez que o Fator de Escala é um valor exponencial e gostamos de utilizar 8, cada redução no valor do Fator de Escala é um enorme impacto negativo para o débito.

Inspeção TLS significa SEGURANÇA! Mas na verdade não! Muitos clientes com proxies querem utilizá-los para inspecionar todo o tráfego, o que significa que o TLS "quebra e inspeciona". Quando o fizer para um site acedido através de HTTPS (questões de privacidade, não obstante) o seu proxy poderá ter de o fazer para 10 ou mesmo 20 fluxos simultâneos durante algumas centenas de milissegundos. Se houver uma transferência grande ou talvez um vídeo envolvido, uma ou mais dessas ligações podem durar muito mais tempo, mas, no geral, a maioria dessas ligações estabelece, transfere e fecha muito rapidamente. Fazer uma interrupção e inspecionar significa que o proxy tem de fazer o dobro do trabalho. Para cada ligação do cliente ao proxy, o proxy também tem de efetuar uma ligação separada de volta ao ponto final. Então, 1 torna-se 2, 2 torna-se 4, 32 torna-se 64...ver para onde vou? Provavelmente dimensionou muito bem a sua solução de proxy para a navegação na Web típica, mas quando tenta fazer o mesmo para as ligações de cliente a Office 365, o número de ligações simultâneas e de longa duração podem ser encomendas de magnitude maiores do que as que dimensionou.

A transmissão em fluxo não é importante, exceto que é

Os únicos serviços no Office 365 que utilizam UDP são o Skype (que em breve será descontinuado) e o Microsoft Teams. O Teams utiliza o UDP para transmissão em fluxo de tráfego, incluindo áudio, vídeo e partilha de apresentações. O tráfego de transmissão em fluxo é transmitido em direto, como quando está a ter uma reunião online com voz, vídeo e apresentação de decks ou realização de demonstrações. Estes utilizam uDP porque se os pacotes forem removidos ou chegarem fora de ordem, é praticamente despercebido pelo utilizador e o fluxo pode continuar.

Quando não permite o tráfego UDP de saída dos clientes para o serviço, estes podem reverter para a utilização de TCP. No entanto, se um pacote TCP for removido, tudo para até que o Tempo Limite de Retransmissão (RTO) expire e o pacote em falta possa ser retransmitido. Se um pacote chegar fora de ordem, tudo para até que os outros pacotes cheguem e possam ser montados novamente por ordem. Ambos conduzem a falhas percetíveis no áudio (lembra-se de Max Headroom?) e vídeo (clicou em alguma coisa... oh, lá está) e levar a um mau desempenho e a uma má experiência de utilizador. E lembras-te do que coloquei acima sobre proxies? Quando força um cliente do Teams a utilizar um proxy, força-o a utilizar o TCP. Agora está a causar impactos negativos no desempenho duas vezes.

Dividir túnel pode parecer assustador

Mas não é. Todas as ligações a Office 365 são por TLS. Temos vindo a oferecer o TLS 1.2 há algum tempo e vamos desativar versões mais antigas em breve porque os clientes legados ainda as utilizam e isso é um risco.

Forçar uma ligação TLS, ou 32 delas, a passar por uma VPN antes de aceder ao serviço não adiciona segurança. Adiciona latência e reduz o débito geral. Em algumas soluções de VPN, força mesmo o UDP a fazer o túnel através de TCP, o que terá novamente um impacto muito negativo no tráfego de transmissão em fluxo. E, a não ser que estejas a fazer uma inspeção TLS, não há nenhuma vantagem, todas as desvantagens. Um tema muito comum entre os clientes, agora que a maioria da sua força de trabalho é remota, é que estão a ver impactos significativos de largura de banda e desempenho ao fazer com que todos os seus utilizadores se liguem através de uma VPN, em vez de configurarem túneis divididos para acesso a Otimizar categoria Office 365 pontos finais.

É uma solução fácil de dividir o túnel e é uma solução que deve fazer. Para obter mais informações, certifique-se de que revê Otimizar a conectividade Office 365 para utilizadores remotos que utilizam o túnel dividido de VPN.

Os pecados do passado

Muitas vezes, a razão pela qual são feitas más escolhas vem de uma combinação de (1) não saber como funciona o serviço, (2) tentar cumprir as políticas da empresa que foram escritas antes de adotar a cloud, e (3) equipas de segurança que podem não estar facilmente convencidas de que há mais do que uma maneira de atingir os seus objetivos. Esperemos que o acima, e as ligações abaixo, ajudem com o primeiro. O patrocínio executivo pode ser necessário para passar o segundo. A resolução dos objetivos das políticas de segurança, em vez dos respetivos métodos, ajuda com a terceira. Desde o acesso condicional à moderação de conteúdos, ao DLP à proteção de informações, à validação de pontos finais a ameaças de zero dias— qualquer objetivo final que uma política de segurança razoável possa ter pode ter conseguido com o que está disponível no Office 365 e sem qualquer dependência da engrenagem de rede no local, túneis VPN forçados e interrupção e inspeção do TLS.

Outras vezes, o hardware que foi dimensionado e comprado antes da organização começar a mudar para a cloud simplesmente não pode ser aumentado verticalmente para lidar com os novos padrões e cargas de tráfego. Se tiver realmente de encaminhar todo o tráfego através de um único ponto de saída e/ou proxy, esteja preparado para atualizar o equipamento de rede e a largura de banda em conformidade. Monitorize cuidadosamente a utilização em ambos, uma vez que a experiência não diminuirá lentamente à medida que mais utilizadores integrarem. Está tudo bem até que o ponto de viragem seja atingido, então todos sofrem.

Exceções às regras

Se a sua organização precisar de restrições de inquilinos, terá de utilizar um proxy com interrupção do TLS e inspecionar para forçar algum tráfego através do proxy, mas não tem de forçar todo o tráfego através do mesmo. Não é uma proposta de tudo ou nada, por isso preste atenção ao que precisa de ser modificado pelo proxy.

Se pretender permitir a divisão de túneis, mas também utilizar um proxy para o tráfego Web geral, certifique-se de que o ficheiro PAC define o que tem de ser direto, bem como a forma como define tráfego interessante para o que passa pelo túnel VPN. Oferecemos ficheiros PAC de exemplo no https://aka.ms/ipaddrs que facilitam a gestão.

Conclusão

Dezenas de milhares de organizações, incluindo quase todas as Fortune 500, usam Office 365 todos os dias para as suas funções críticas da missão. Fazem-no de forma segura e fazem-no através da Internet.

Independentemente dos objetivos de segurança que tem em jogo, existem formas de os alcançar que não requerem ligações VPN, servidores proxy, interrupção e inspeção do TLS ou saída centralizada da Internet para obter o tráfego dos seus utilizadores fora da sua rede e para o nosso o mais rápido possível, o que proporciona o melhor desempenho, quer a sua rede seja a sede da empresa, um escritório remoto ou esse utilizador que trabalha em casa. A nossa documentação de orientação baseia-se na forma como os serviços Office 365 são criados e para garantir uma experiência de utilizador segura e eficaz.