Como incorporar segurança como um recurso SaaS: um guia

Nesta postagem, vou mostrar como fornecer conectividade mais granular e segura de e para uma plataforma SaaS. O resultado final é uma solução holística que parece uma extensão natural da plataforma SaaS e é oferecida como um recurso para planos corporativos ou como um diferencial competitivo para todos os seus clientes. O tempo total necessário para executar a demonstração é de apenas alguns minutos. Também irei me aprofundar no que está acontecendo nos bastidores para explicar como a mágica funciona.

Primeiro, deixe-me explicar por que surge essa necessidade específica e destacar as deficiências nas implementações tradicionais. Porque essas abordagens antigas não funcionam mais.

Você precisa começar a pensar na segurança como um recurso. Se você é vice-presidente de engenharia, se é gerente de produto, proprietário de produto, dedique tempo à segurança e deixe seus desenvolvedores criarem uma infraestrutura melhor e mais segura.

- Joel Spolsky , fundador do Stack Overflow

Os produtos de maior sucesso na próxima década serão aqueles que perceberem que as abordagens do status quo já não são suficientemente boas. Você também não precisa acreditar na palavra de Joel; leia os detalhes do recentemente anunciado Private Cloud Compute da Apple. Uma das empresas de maior sucesso nas últimas duas décadas está afirmando claramente que segurança, privacidade e confiança serão um diferencial fundamental.

Eles até discutem como o uso atual de protocolos como o TLS não pode fornecer as garantias de segurança e privacidade de ponta a ponta que os clientes devem esperar.

Trabalhei na conexão de sistemas entre si há muitos anos, uma tarefa que exigia muito trabalho nos primeiros estágios da minha carreira. Nossa empresa estava crescendo e faríamos um patch da sala de servidores do prédio atual para o sistema que acabamos de instalar no novo prédio. O novo escritório ficava a poucos quarteirões dali e estávamos trabalhando com a empresa de telecomunicações local para instalar uma linha dedicada.

Na época, conectar duas redes separadas tinha uma realidade óbvia e fisicamente tangível.

Todos nós passamos daqueles dias. Agora, as pilhas de tecnologia modernas são mais complicadas; uma série de aplicativos interconectados espalhados por todo o mundo, executados na nuvem pelas melhores empresas de produtos. Ao longo de décadas, evoluímos. Hoje, é raro que duas empresas distintas realmente queiram conectar suas redes inteiras entre si – são aplicativos e cargas de trabalho específicos dentro de cada rede que precisam se comunicar.

Mesmo assim, continuamos a usar abordagens antigas como forma de conectar nossos sistemas de forma “segura”.

A passagem real dos cabos foi abstraída, mas estamos praticamente fazendo a mesma coisa. Essas abordagens antigas expõem você transitivamente a um número incontável de redes, o que representa uma enorme superfície de ataque pronta para exploração.

A necessidade de se conectar a um sistema privado

O que as pessoas querem dizer quando dizem “nuvem” ou “no local” tornou-se obscuro nas décadas anteriores. Para evitar qualquer confusão, criarei um cenário hipotético para nós:

• Plataforma Initech: Esta é uma plataforma SaaS que você opera. É elástico e escalonável e está hospedado em um dos principais provedores de nuvem. Os clientes compram a plataforma para melhorar seus processos DevOps, pois ela fornece visibilidade sobre uma série de métricas úteis e fornece feedback útil diretamente em seus fluxos de trabalho de desenvolvimento.

• ACME Corp: Este é um grande cliente da Initech que você deseja apoiar. Eles administram muita infraestrutura em vários locais. É "no local" no sentido clássico de estar dentro do seu próprio data center? Está dentro de seu próprio VPC em um dos principais provedores de nuvem? Não importa! Os sistemas dos clientes estão sendo executados em uma ou mais redes que a Initech não controla, às quais não temos acesso e que não são diretamente acessíveis pela Internet pública.

Envolvimento proativo em fluxos de trabalho de desenvolvedores

Na construção da versão inicial da Plataforma Initech, há muitos clientes potenciais com quem trabalhar para provar a adequação do produto ao mercado. Ele se integrará às APIs públicas dos principais provedores de sistemas de controle de versão (por exemplo, GitHub, GitLab, Bitbucket, etc.), usará commit/webhooks para reagir a eventos, enviar resultados para o fluxo de trabalho e tudo funcionará conforme o esperado.

Isso é ótimo enquanto o produto é passivo e simplesmente reage a eventos iniciados por alguém na ACME Corp. Muitos serviços desejam agregar valor avaliando mudanças externas no mundo e sendo proativos na promoção de melhorias para seus clientes.

Pense nos muitos serviços de verificação de dependência ou segurança: se houver uma nova divulgação de vulnerabilidade, eles desejam criar uma solicitação pull/merge em todos os repositórios afetados o mais rápido possível. Os serviços VCS totalmente gerenciados com APIs públicas fornecem maneiras de habilitar isso; no entanto, as versões auto-hospedadas desses produtos não possuem uma API acessível publicamente.

Os clientes que optam por auto-hospedar esses sistemas normalmente preferem grandes empresas, então agora nos deparamos com algumas decisões difíceis: a Initech não consegue vender seu produto para esses clientes de alto valor? Os clientes precisam comprar uma versão reduzida do produto que não possui um dos recursos mais valiosos? Ou pedimos-lhes que reavaliem algum aspecto da sua postura de segurança e rede para dar acesso à Initech?

Acesso a dados privados

A Initech precisa consultar um banco de dados para exibir sua solução de relatórios personalizados. Este não é um problema exclusivo da Initech, já que quase todas as Plataformas de Dados do Cliente (CDP) ou ferramentas de visualização têm o mesmo problema: os clientes não querem tornar os seus dados privados acessíveis a partir da Internet pública, por isso normalmente estarão num banco de dados em uma sub-rede privada.

Os problemas com nossas abordagens atuais

Como eu disse anteriormente, as pilhas de tecnologia modernas evoluíram para uma série de aplicativos interconectados. No entanto, a forma como conectamos esses aplicativos mudou apenas um pouco em relação à maneira como conectávamos redes há décadas. Embora essas abordagens sejam convenientes e familiares, elas nunca foram projetadas para os casos de uso que temos hoje.

Em vez disso, eles estão tentando fazer os menores ajustes possíveis na maneira como as coisas funcionavam para tentar chegar mais perto de como precisamos que as coisas funcionem hoje.

Colocando Sistemas na Internet Pública

A opção de implantação padrão para a maioria dos sistemas privados é localizá-los em uma rede privada, com uma sub-rede privada, sem endereços IP públicos. Existem boas razões para isso! A opção mais fácil para a Initech se conectar a esse sistema privado seria pedir à ACME Corp que fornecesse um endereço IP público ou nome de host que pudesse ser acessado pela Internet.

Isto é mau.

Todas as boas razões para colocar inicialmente um sistema numa rede privada desligada do mundo desaparecem imediatamente. Este sistema agora pode ser acessado por toda a Internet pública, permitindo que milhares de possíveis hackers tentem constantemente entrar no sistema com força bruta ou simplesmente façam DoS nele. Você está a apenas uma credencial vazada, CVE ou outro problema de ser adquirido.

Proxies Reversos

Outra abordagem é colocar um proxy reverso na frente do sistema. Não estou falando apenas de algo como nginx e HA Proxy; há toda uma categoria de serviços hospedados ou gerenciados que também se enquadram nessa descrição.

Isto tem a vantagem de que a ACME Corp não está mais colocando um sistema privado diretamente na Internet pública. O proxy reverso também adiciona a capacidade de limitar a taxa ou ajustar as restrições de acesso para mitigar possíveis ataques DoS. Esta é uma melhoria profunda da defesa, mas a ACME Corp ainda permite que toda a Internet pública alcance e tente atacar o proxy.

Se estiver comprometido, fará o que um proxy faz: deixará o tráfego chegar ao destino pretendido.

Listas de permissões de IP

Uma melhoria incremental é a Initech fornecer uma lista de IPs dos quais enviarão solicitações e fazer com que a ACME Corp gerencie seu firewall e regras de roteamento para permitir solicitações apenas desses endereços IP. No entanto, isso não é uma grande melhoria.

Na Initech, você não vai querer ter um acoplamento forte entre as instâncias atuais do aplicativo e os endereços IP; você desejará a flexibilidade para poder dimensionar a infraestrutura conforme necessário, sem a necessidade de informar constantemente os clientes sobre novos endereços IP.

Portanto, os endereços IP provavelmente pertencerão a um gateway NAT ou servidor proxy. A ACME Corp pode presumir que bloquear o acesso a apenas um ou dois endereços IP de origem significa que apenas uma ou duas máquinas remotas têm acesso à sua rede.

A realidade é que qualquer coisa na rede remota que possa enviar uma solicitação através do gateway ou proxy NAT também terá acesso à rede ACME Corp. Isso não permite a entrada de um único aplicativo ou máquina; você permitiu uma rede remota inteira.

Ainda mais preocupante é que os endereços de origem IP são falsificados trivialmente . Um invasor em potencial seria capaz de criar uma solicitação bem formada, falsificar o endereço de origem e enviar dados ou instruções para a rede ACME Corp. Os fornecedores de SaaS, incluindo a Initech, também precisam inevitavelmente documentar a lista de endereços IP atuais para que haja uma lista pronta de IPs para tentar personificar.

Quanto mais sofisticada for a sua abordagem à filtragem de IP, mais sofisticado um invasor precisa ser para comprometê-la, mas nenhuma delas é perfeita. Já ouvi pessoas afirmarem no passado que a falsificação de IP só serve para ataques DDoS porque, na maioria dos casos, o invasor não consegue receber a resposta e, portanto, não pode fazer nada de útil.

Pense nos sistemas que estamos conectando: quão confiante você está de que não há chamadas de API do tipo "dispare e esqueça" que não criarão/atualizarão/destruirão dados valiosos obedientemente? Uma boa segurança é mais do que apenas prevenir a exposição de dados, é também protegê-los e garantir a sua integridade.

Se você for um alvo valioso, como uma grande instituição financeira, os invasores terão motivação para usar abordagens como essa para lançar ataques MitM e interceptar fluxos de comunicação . Se seus clientes e clientes potenciais são alvos valiosos, isso também faz de você um alvo valioso.

Redes Privadas Virtuais (VPNs)

As VPNs são uma solução comum em muitas empresas para permitir que os funcionários se conectem à “rede corporativa” quando estão fora do escritório. Eles também são usados para permitir que outros sistemas se conectem a uma rede existente.

O caso de uso do qual estamos falando aqui é diferente. Trata-se de permitir que duas empresas distintas, um produto SaaS e seu(s) cliente(s), possam se comunicar entre si.

Em muitos desses casos, há apenas um sistema em cada extremidade da conexão que deve ser capaz de se comunicar entre si. Em vez disso, procuramos uma ferramenta projetada para conectar redes inteiras. É como executar um patch virtual do roteador de uma empresa para o roteador de outra.

Se eu pedisse para você fazer a versão física disso, para conectar um cabo do seu ambiente de produção diretamente ao ambiente de produção de outra empresa, você provavelmente daria uma pausa. Muita pausa. E por um bom motivo. Mas as VPNs são “virtuais” e “privadas” e tão fáceis (em relação à utilização de um cabo) e tão onipresentes que nem pensamos muito nisso.

Se tudo o que você precisava fazer era conectar uma coisa em cada rede, você usou um instrumento muito contundente para o que deveria ser uma tarefa muito precisa.

Você ainda pode realizar a tarefa precisa usando uma VPN, mas existem camadas de controles no nível da rede e regras de roteamento que você precisa garantir que estejam em vigor para fechar todas as portas para apenas aquela que você deseja abrir em cada rede. É outro exemplo de como temos ferramentas e abordagens que são excelentes para a finalidade para a qual foram projetadas, mas estamos dando passos incrementais na forma como as usamos para forçá-las a trabalhar com nossas necessidades evoluídas.

Fazer isso com segurança significa aumentar a complexidade e esperar que obtenhamos todos os detalhes de todas essas camadas corretamente, o tempo todo. Errar acarreta riscos de acesso transitivo além das intenções originais.

Você não pode confiar na rede

E se eu lhe dissesse que, independentemente de quanto tempo, pessoas e dinheiro você investe em seu programa de segurança, é quase certo que sua rede estará exposta a uma falha de segurança facilmente explorável? …

dados da indústria mostram que menos de 1% das maiores empresas do mundo ainda não tomaram quaisquer medidas para proteger a sua rede desta ameaça nova e emergente…

A história nos ensinou que a coisa certa a fazer deve ser a coisa mais fácil de fazer. Isso é particularmente crítico para desenvolvedores de software e para proteção contra componentes intencionalmente maliciosos. Esta lenta curva de adoção da tecnologia de segurança... permitiu efetivamente que os malfeitores vissem o potencial, inovassem e impulsionassem o crescimento espetacular do crime cibernético

- Mitchell Johnson , Sonatipo

O problema com cada uma dessas abordagens é que assumir que é seguro requer muitas suposições adicionais: que ninguém na Internet tentará comprometê-lo, que você pode confiar no IP de origem das solicitações, que a rede remota é composta apenas por bons atores , que essas suposições continuarão a ser verdadeiras agora e indefinidamente no futuro... e que todas essas suposições também são verdadeiras para todas as redes às quais você se conectou, e qualquer rede à qual eles se conectaram, e qualquer rede...

Dê uma olhada em como isso pode ser da perspectiva da ACME Corp:

Não são apenas duas redes e duas empresas agora conectadas entre si; são muitas redes. Cada fornecedor de SaaS terá seu próprio conjunto de serviços que utiliza, o que multiplica isso ainda mais. Você não só não pode confiar na rede, como também não pode confiar na rede de mais ninguém. Qualquer participante nesta imagem está apenas com uma configuração incorreta da rede ou com uma dependência comprometida, longe de transmitir esse risco através da(s) rede(s).

E esta imagem é o exemplo mais ampliado de um fractal deste problema! Diminua o zoom e cada fornecedor estará conectado ao seu próprio conjunto de clientes, aos seus próprios fornecedores, aos seus próprios clientes... a área de superfície de risco cresce exponencialmente.

Então, vamos resolver isso!

Podemos incorporar a segurança como um recurso em nosso produto em minutos! Aumentaremos o nível de segurança fornecendo uma solução mais focada e granular. Também vamos parar de empurrar os problemas para clientes como a ACME Corp, pedindo-lhes que façam alterações no nível da rede.

Em vez disso, vamos transformar a conectividade segura em uma preocupação de nível de aplicação e fornecer uma experiência holística de produto, estendendo a Plataforma Initech aos locais específicos onde ela precisa estar.

O exemplo aqui mostra como a plataforma Initech pode estabelecer uma conexão com um servidor GitHub Enterprise auto-hospedado gerenciado pela ACME Corp.

Leva apenas alguns minutos para girar todas as peças necessárias! Para saber como fazer isso, dê uma olhada em nosso tour de código para construir a base de um agente auto-hospedado .