As ofertas de Software como Serviço (SaaS) estão se tornando cada vez mais comuns em todos os setores, à medida que as organizações buscam formas cada vez mais dinâmicas e flexíveis de aproveitar os recursos de software, garantindo, ao mesmo tempo, estabilidade operacional, transparência de custos, escalabilidade dinâmica e agilidade.
No entanto, antes de chegarmos ao aplicativo fornecido por terceiros, precisamos ter vários componentes implementados para permitir o acesso dos nossos usuários, como conectividade de rede, armazenamento, computação (na camada de infraestrutura), virtualização, sistema operacional, middleware, ambiente de execução e tudo o que for necessário para que o aplicativo seja executado na camada de serviços. Somente então entramos no âmbito da configuração do RBAC, do gerenciamento de usuários e da distribuição do aplicativo aos usuários finais.
Também é importante observar que, embora muitas das camadas acima estejam passando por uma consolidação e uma sobreposição das tecnologias subjacentes dentro da função, as organizações geralmente têm equipes distintas, com processos próprios, responsáveis por suas respectivas camadas. Na maioria das vezes, há várias equipes atuando em cada camada.
Este artigo apresenta as ideias e inovações de Thad Széll (engenheiro distinto da UBS) e Nuno Ferreira (CTO de campo da Volterra) para permitir que as organizações adotem aplicações SaaS em tempo real, de forma segura e privada, sem comprometer nem contaminar o ambiente existente. O foco inicial foi o Microsoft Office 365.a
Como todos sabemos, os aplicativos SaaS geralmente são acessados pela Internet pública, e é aí que surge o primeiro conjunto de problemas. O primeiro problema de infraestrutura decorre do fato de que, anteriormente, o aplicativo estava em uma infraestrutura controlada e predominantemente estática, mas agora será acessado pela Internet, que é extremamente dinâmica e não está sob o controle de uma única entidade.
Alguns provedores de SaaS podem disponibilizar 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 esses mecanismos, as organizações precisarão, no mínimo:
Estabelecer peering (no nível da rede) com o provedor de SaaS e manter as relações de roteamento. Injetar/anunciar os endereços IP públicos do provedor de SaaS na rede corporativa. Tratar o serviço como uma extranet ou DMZ e adicionar camadas de segmentação e segurança. Nos casos em que o provedor de SaaS oferece ao cliente apenas um serviço de VPN, é necessário um dispositivo para estabelecer e manter essa VPN. Observe que essas tecnologias não resolvem o problema de latência.
Ter um dispositivo de proxy de encaminhamento/NAT pode resolver algumas questões de segurança, mas NÃO resolverá o problema de roteamento nem a necessidade de inserir 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 DNS e endpoints publicados mudam com muita frequência. Portanto, é necessário implementar mecanismos operacionais para manter o peering, a injeção e o anúncio de rotas, bem como os controles de segurança.
Uma solução que permita o uso de proxy de encaminhamento/NAT sem a necessidade de roteamento é, portanto, mais elegante e necessária.
Tomemos o Office 365 como exemplo. A Microsoft está ampliando sua presença na nuvem com o Azure, e os Serviços de Aplicativos da Microsoft estão crescendo a cada dia. Essa plataforma permite que grandes empresas tenham conexões físicas privadas, dedicadas e de alta velocidade com o Azure, chamadas ExpressRoute.
A Microsoft poderia, portanto, solucionar os problemas mencionados acima (relacionados à privacidade e à latência), permitindo que os funcionários das empresas acessassem o Office 365 por meio desse circuito privado dedicado do ExpressRoute.
O ExpressRoute para Office 365 oferece uma rota alternativa para muitos serviços do Office 365 voltados para a Internet. A arquitetura do ExpressRoute para Office 365 baseia-se no anúncio dos prefixos de IP públicos dos serviços do Office 365 que já podem ser acessados pela Internet nos circuitos do ExpressRoute provisionados, para que esses prefixos de IP sejam posteriormente redistribuídos em sua rede. Com o ExpressRoute, você efetivamente habilita várias rotas diferentes para os serviços do Office 365: a Internet e o ExpressRoute. Esse estado de roteamento em sua rede pode representar uma mudança significativa na forma como a topologia da rede interna é projetada e protegida.
Ok, então talvez não seja tão privado assim.
A imagem abaixo representa este cenário:
Essa abordagem apresenta três desafios distintos para as equipes de rede e segurança:
Roteamento de rede e NAT: a equipe de infraestrutura de rede da empresa precisará inserir um espaço de endereços IP publicamente roteável na rede corporativa para permitir que os usuários sigam a rota preferencial (via ExpressRoute). Além disso, para evitar qualquer exposição da rede corporativa à Microsoft, a equipe de rede também precisará implementar NAT em direção a essa rede da Microsoft. Isso não só traz a complexidade operacional de manter o emparelhamento BGP (juntamente com o NAT) com a Microsoft, como também exige um planejamento cuidadoso para lidar com as complexidades de uma rede em que o roteamento está disponível tanto por meio de um circuito dedicado, com rotas inseridas na rede principal, quanto pela Internet. Gerenciamento de alterações de segurança: os endereços do Office 365 mudam periodicamente e, portanto, essas alterações precisam ser refletidas na infraestrutura interna de segurança e de proxy da empresa. Não fazer isso pode resultar em perda intermitente ou total da conectividade com os serviços do Office 365 quando o circuito do ExpressRoute estiver habilitado. A Microsoft fornece um documento abrangente e atualizado regularmente (e uma API REST) com uma lista de domínios, endereços IP e portas TCP/UDP que precisam ser configurados e continuamente atualizados nos dispositivos corporativos de segurança e roteamento para aplicar as políticas corporativas de segurança e governança. Visibilidade operacional e de segurança: os dispositivos NAT oferecem pouca ou nenhuma visibilidade da aplicação. Então, como abordamos esse cenário quando nenhuma opção parecia ser boa o suficiente?
Desenvolvemos uma solução elegante que elimina a necessidade de gerenciar políticas de segurança e uma infraestrutura de rede complexa, ao mesmo tempo que oferece aos funcionários os benefícios da conectividade do ExpressRoute para acessar o Office 365 e serviços de aplicativos relacionados.
A pilha integrada de rede e segurança da Volterra inclui um roteador de aplicações com recursos programáveis de proxy e balanceamento de carga para atender a essa necessidade. Além desses recursos, a Volterra oferece um caminho simples para que as empresas avancem rumo à segurança de confiança zero.
Em linhas gerais, a empresa terá um cluster do Volterra Application Gateway emparelhado com o roteador ExpressRoute, no qual a Microsoft disponibiliza as rotas e os serviços do Office 365. O Volterra Application Gateway realiza a descoberta automatizada dos endpoints do Office 365 por meio desse roteador, permitindo que as empresas acessem os serviços do Office 365 a partir dele. Essa inovação elimina a necessidade de os operadores gerenciarem mais um processo para converter configurações dinâmicas em regras na infraestrutura. A inovação de descoberta automática do Volterra Gateway permite que os clientes alterem constantemente o destino de suas solicitações, e o gateway acionará a descoberta automática e garantirá a integridade TLS de todas as solicitações recebidas.
A segunda parte da solução consiste em disponibilizar esses serviços aos usuários corporativos sem anunciar as rotas públicas da Microsoft na rede empresarial. Isso pode ser feito de duas maneiras:
O primeiro método consiste em fazer isso diretamente a partir do cluster do Volterra Application Gateway no Azure, por meio do circuito do ExpressRoute. Observe que o único IP anunciado na rede corporativa será o endereço IP do cluster do Volterra Application Gateway no Azure. Para fins ilustrativos, estamos considerando que o gateway está no Azure, mas ele pode estar localizado em qualquer lugar, desde que estas duas condições sejam atendidas: a. Os usuários conseguem acessar o gateway para enviar tráfego a ele (ou o gateway intercepta esse tráfego); b. O gateway está conectado a um circuito do ExpressRoute no qual os endpoints do Office 365 estejam localizados ou possam ser descobertos. O segundo método consiste em adicionar um (ou vários) clusters do Volterra Application Gateway nas instalações corporativas (e em data centers privados). Em seguida, configuraremos políticas para disponibilizar, no cluster local do Application Gateway, os serviços de endpoint do Office 365 descobertos. Esses endpoints são descobertos por meio do Volterra Application Gateway localizado na nuvem do Azure (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, mantendo todo o tráfego criptografado. As imagens abaixo representam esses cenários:
O cluster do Volterra Application Gateway também implementa recursos de escalabilidade automática, o que significa que, quando um gateway ultrapassa um limite específico, ele inicia 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 da empresa são:
Simplicidade operacional com políticas centralizadas e gerenciamento baseado em SaaS. Proxy, segurança e roteamento integrados/unificados com plano de dados programável. Visibilidade granular e abrangente, registros e métricas de uso e acesso a aplicações. Ao proporcionar simplicidade e excelência operacional, acreditamos que esta solução seja a verdadeira resposta para organizações que buscam atingir objetivos semelhantes aos do UBS, pois permite garantir que o acesso privado a serviços SaaS, como o Office 365, seja utilizado sem a necessidade de tornar sua rede corporativa “disponível para redes públicas ou até mesmo parte delas”.
Sobre o autor
Publicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...