Acessando aplicativos de nuvem pública (também conhecidos como SaaS) …privadamente

As ofertas de Software como Serviço (SaaS) estão se tornando cada vez mais prevalentes em todos os setores, à medida que as organizações buscam maneiras cada vez mais dinâmicas e flexíveis de alavancar o software, garantindo estabilidade operacional, transparência de custos, escala dinâmica e agilidade.

Antes de chegarmos ao aplicativo fornecido por terceiros, no entanto, há vários componentes que precisamos ter em vigor para permitir que nossos usuários obtenham acesso, como: conectividade de rede, armazenamento, computação (na camada de infraestrutura), virtualização, sistema operacional, middleware, tempo de execução e tudo o que é necessário para permitir que o aplicativo seja executado na camada de serviços. Somente então você estará no âmbito da configuração do RBAC, do gerenciamento de usuários e da distribuição do aplicativo para seus usuários finais.

Também é importante observar que, embora muitas das camadas acima estejam passando por uma consolidação e sobreposição na tecnologia subjacente dentro da função, as organizações geralmente têm equipes diferentes com processos exclusivos que possuem sua camada específica. Na maioria das vezes, há várias equipes operando em cada camada.

Este artigo apresenta as ideias e inovações que Thad Széll (Engenheiro Distinto da UBS) e Nuno Ferreira (CTO de Campo da Volterra) têm para permitir que as organizações adotem aplicativos SaaS em tempo real, de forma segura e privada, sem comprometer e contaminar o ambiente existente. O foco deles começou com o Microsoft Office 365.a

Como todos sabemos, os aplicativos SaaS geralmente são acessados pela Internet pública e é aqui que surge o primeiro conjunto de problemas. O primeiro problema de infraestrutura é derivado do fato de que anteriormente o aplicativo estava em uma infraestrutura controlada, principalmente estática, e agora ele será acessado pela Internet, que é extremamente dinâmica e não está sob o controle de uma entidade específica.

Alguns provedores de SaaS têm a capacidade de fornecer circuitos dedicados (por exemplo, o Azure oferece o ExpressRoute) ou VPNs para que as organizações se conectem a eles de forma privada. Para adotar tais mecanismos, as organizações precisarão pelo menos:

Faça peering (no nível de rede) com o provedor de SaaS e mantenha relacionamentos de roteamento. Injete/apresente os endereços IP públicos do provedor de SaaS na rede corporativa. Trate o serviço como uma extranet ou DMZ e sobreponha níveis de segmentação e segurança. Nos casos em que o provedor de SaaS oferece apenas um serviço de VPN ao cliente, é necessário um dispositivo para construir e manter essa VPN. Observe que essas tecnologias não resolvem o problema de latência.

Ter um dispositivo proxy/NAT de encaminhamento pode resolver alguns problemas de segurança, mas NÃO resolverá o problema de roteamento e a necessidade de injetar endereços IP públicos de terceiros na rede corporativa.

Além disso, os provedores de SaaS costumam ser extremamente dinâmicos e seus endereços anunciados, nomes de DNS e pontos de extremidade publicados mudam com muita frequência e, portanto, mecanismos operacionais precisam estar em vigor para manter os controles de peering/injeção/publicidade e segurança.

Uma solução que permita o encaminhamento de proxy/NAT sem a necessidade de roteamento é, portanto, mais elegante e necessária.

Vamos pegar o Office 365 como exemplo. A Microsoft está expandindo sua presença na nuvem com o Azure e os Serviços de Aplicativos da Microsoft estão se expandindo a cada dia. Esta plataforma permite que grandes empresas tenham links físicos privados, dedicados e de alta velocidade com o Azure, chamados ExpressRoute.

Portanto, a Microsoft poderia resolver os problemas mencionados acima (em torno de privacidade e latência) permitindo que funcionários da empresa acessassem o Office 365 por meio desse circuito ExpressRoute privado dedicado.

O ExpressRoute para Office 365 fornece um caminho de roteamento alternativo para muitos serviços do Office 365 voltados para a Internet. A arquitetura do ExpressRoute para Office 365 é baseada na publicidade dos prefixos IP públicos dos serviços do Office 365 que já estão acessíveis pela Internet em seus circuitos ExpressRoute provisionados para redistribuição subsequente desses prefixos IP em sua rede. Com o ExpressRoute, você habilita efetivamente vários caminhos de roteamento diferentes para serviços do Office 365: a Internet e o ExpressRoute. Esse estado de roteamento na sua rede pode representar uma mudança significativa na forma como sua topologia de rede interna é projetada e protegida.

Ok, talvez não seja tão privado assim.

A imagem abaixo representa esse cenário:

Essa abordagem apresenta três desafios distintos para equipes de rede e segurança:

Roteamento de rede e NAT A equipe de infraestrutura de rede corporativa precisará injetar espaço IP roteável publicamente em sua rede corporativa para permitir que os usuários sigam o caminho preferido (via ExpressRoute). Além disso, para evitar qualquer exposição da rede corporativa à Microsoft, a equipe de rede também será obrigada a implementar o NAT nessa rede da Microsoft. Isso não só traz complexidade operacional para manter o peering BGP (junto com NAT) com a Microsoft, mas também requer um planejamento cuidadoso para acomodar as complexidades de rede de ter roteamento disponível por meio de um circuito dedicado com rotas injetadas na sua rede principal e na Internet. Os endereços de gerenciamento de alterações de segurança do Office 365 mudam de tempos em tempos e, portanto, essas alterações precisam ser refletidas na segurança interna e na infraestrutura de proxy da empresa. Não fazer isso pode resultar em perda intermitente ou total de conectividade com os serviços do Office 365 quando o circuito ExpressRoute estiver habilitado. A Microsoft fornece um documento abrangente e atualizado regularmente (e API REST) que fornece uma lista de domínios, endereços IP e portas TCP/UDP que precisam ser configurados e continuamente atualizados nos dispositivos de segurança e roteamento corporativos para impor políticas de segurança e governança corporativas. Visibilidade operacional e de segurança Há pouca ou nenhuma visibilidade com dispositivos NAT no aplicativo. Então, como abordamos esse cenário quando nada parecia ser bom o suficiente?

Elaboramos uma solução elegante que elimina a necessidade de gerenciar infraestrutura de rede complexa e políticas de segurança, ao mesmo tempo em que oferece aos funcionários os benefícios da conectividade ExpressRoute para acessar o Office 365 e serviços de aplicativos relacionados.

A pilha de rede e segurança integrada da Volterra inclui um roteador de aplicativo com proxy programável e recursos de balanceamento de carga para atender a essa necessidade. Além desses recursos, o Volterra fornece um caminho simples para as empresas evoluírem para segurança de confiança zero.

Em um nível alto, a Enterprise terá um cluster do Volterra Application Gateway fazendo peering com o roteador ExpressRoute, onde a Microsoft apresenta as rotas/serviços do Office 365. O Volterra Application Gateway realiza a descoberta automatizada dos pontos de extremidade do Office 365 por meio deste roteador, permitindo que as empresas acessem os serviços do Office 365 a partir daí. Essa inovação permite que as operadoras eliminem a necessidade de gerenciar mais um processo para traduzir a configuração dinâmica em regras em sua infraestrutura. A inovação do Volterra Gateway Auto-Discovery permite que os clientes alterem o destino de suas solicitações constantemente e o gateway acionará a descoberta automática e a integridade TLS para qualquer solicitação recebida.

A segunda parte da solução é expor esses serviços aos usuários corporativos sem anunciar as rotas públicas da Microsoft dentro da rede corporativa. Isto pode ser alcançado de duas maneiras:

O primeiro método é executar isso diretamente do cluster do Volterra Application Gateway no Azure pelo circuito ExpressRoute. Observe que a única injeção de IP na rede corporativa será o endereço IP do cluster do Volterra Application Gateway no Azure. Para fins de ilustração, estamos dizendo que o gateway está no Azure, mas pode estar localizado em qualquer lugar, desde que estas 2 condições sejam atendidas: a. Os usuários podem acessar o gateway para enviar tráfego para ele (ou o gateway o intercepta) b. O gateway é conectado a um circuito de Rota Expressa onde os pontos de extremidade do Office 365 estão localizados/podem ser descobertos. O segundo método é adicionar um (ou muitos) clusters do Volterra Application Gateway dentro das instalações corporativas (e DCs privados). Em seguida, configuraremos políticas para expor serviços de ponto de extremidade descobertos do Office365 no cluster do Application Gateway local. Esses pontos de extremidade são descobertos por meio do Volterra Application Gateway, que fica no Azure Cloud (conforme explicado na primeira parte). Além disso, a equipe de operações corporativas pode configurar políticas adicionais de segurança e autenticação enquanto criptografa todo o tráfego. As imagens abaixo representam esses cenários:

O cluster do Volterra Application Gateway também implementa recursos de dimensionamento automático, o que significa que quando um gateway ultrapassa um limite específico, ele aciona outro e o adiciona ao cluster.

Outros recursos da solução Volterra que oferecem benefícios significativos às equipes de rede, segurança e operações corporativas são:

Simplicidade operacional com política centralizada e gerenciamento baseado em SaaS Proxy integrado/unificado, segurança e roteamento com plano de dados programável Visibilidade granular e rica, registro e métricas de uso e acesso de aplicativos Ao atingir simplicidade e excelência operacional, acreditamos que esta solução é a resposta real para organizações que tentam atingir objetivos semelhantes aos do UBS, onde podemos garantir que o acesso privado a serviços SaaS, como o Office 365, seja usado sem a necessidade de tornar sua rede corporativa "disponível para, ou mesmo parte de, redes públicas".