O poder da Minimum Viable Network

Compreender a rede em nuvem é um dos maiores ajustes para as organizações que iniciam a sua jornada na nuvem. Ao analisar o esquema de endereçamento e os componentes, tudo se parece com uma rede IP. E, na maior parte das perspetivas, é mesmo — mas, em muitas outras áreas, não é. Uma rede definida por software (SDN) – como as oferecidas na nuvem – não está sujeita às mesmas limitações de uma rede física, e isso pode ser bastante confuso no início.

Em vez de tentar perceber em que medida a SDN é diferente da sua rede física, concentremo-nos no que precisa que a rede faça e, sobretudo, no que não deve ser permitido. Talvez tenha idade suficiente para se lembrar de um conceito chamado “negação por omissão”, que significava que, a menos que permitisse explicitamente uma ligação, esta era bloqueada por predefinição. Depois surgiu a web e deixou de ser possível restringir a porta 80 ou 443, uma vez que praticamente todas as aplicações usavam essas portas. Além disso, a “negação por omissão” nunca chegou verdadeiramente a ultrapassar o perímetro e as nossas redes internas tendiam a ser planas e abertas, apoiando-se numa DMZ para filtrar o tráfego malicioso vindo do exterior. Como violação após violação tem demonstrado, este modelo é apenas moderadamente eficaz.

Mas a SDN permite-nos chegar muito mais perto da negação por omissão, através de um conceito a que chamamos “Minimum Viable Network”, que possibilita construir redes personalizadas apenas com as peças necessárias para cumprir a função, e nada mais.

Uma Minimum Viable Network deve determinar a arquitetura da aplicação e depois criar APENAS a rede necessária para suportar essa aplicação, impondo encaminhamento e grupos de segurança de privilégio mínimo e recorrendo também a componentes PaaS, como os balanceadores de carga da nuvem. Isto transforma efetivamente a rede de comutação de pacotes numa rede de comutação de circuitos, na medida em que os componentes da aplicação APENAS podem comunicar com os outros componentes permitidos, e nada consegue analisar o tráfego entre eles (exceto, em alguns casos, o fornecedor de nuvem). A rede descarta todo o restante tráfego. Isto elimina a necessidade de construções como a tradicional DMZ ou as zonas de rede, dado que a própria rede é, na sua totalidade, de privilégio mínimo e negação por omissão.

Tornemos isto um pouco mais concreto com um exemplo. Pode criar uma pilha de aplicações tradicional de 3 camadas com um Application Load Balancer voltado para o exterior, apoiado por um servidor web numa sub-rede privada que APENAS aceita tráfego do balanceador de carga. Os servidores web só conseguem ligar-se a servidores de aplicações que aceitem ligações vindas deles. Do mesmo modo, os servidores de aplicações só podem enviar tráfego para bases de dados que permitam essas ligações. Cada camada é de negação por omissão e só permite ligações de entrada a partir dos balanceadores de carga e ligações de saída para as bases de dados. Em muitos casos, é possível implementar isto sem qualquer ligação à Internet (em sub-redes privadas), à exceção dos balanceadores de carga públicos, que são construções PaaS altamente seguras mantidas pelo fornecedor de nuvem.

Em vez de construir a rede e colocar as aplicações lá dentro, concebe as aplicações e depois adapta a rede às necessidades da aplicação. Isto reduz drasticamente a superfície de ataque da pilha de aplicações e reduz proporcionalmente o seu risco.

Usámos estes princípios quando construímos o site securosis.com, como pode ver no diagrama de arquitetura abaixo. Se olharmos para esse desenho com um olhar de segurança de rede, vemos:

• O acesso é restringido a partir do WAF na nuvem, para que apenas tráfego limpo chegue à VPC.
• Os balanceadores de carga de aplicações (ALB) são os únicos recursos em sub-redes voltadas para o exterior e apenas permitem tráfego 80/443.
• Todas as instâncias estão em sub-redes privadas e apenas aceitam tráfego dos ALB.
• A instância “admin” aceita inícios de sessão, mas apenas a partir de uma VPN alojada num ambiente diferente.
• Não são apresentadas as sub-redes da base de dados RDS, que são também exclusivamente privadas e apenas aceitam tráfego das instâncias. Se forem necessários inícios de sessão diretos ou acesso RDBMS para tratamento de dados, as regras dos grupos de segurança são alteradas para conceder acesso temporário.
• As ligações ao S3 são feitas através de um endpoint de serviço, eliminando a necessidade de um NAT Gateway para acesso à Internet.
• O SSH está desativado nas instâncias que não são de administração. Estas são autoescaláveis e imutáveis e só são modificadas através da alteração da imagem base.
• Não existem grupos de segurança autorreferenciados (grupos de segurança que permitem acesso interno), de modo a impedir ataques horizontais. Os grupos de segurança na AWS funcionam ao nível do recurso, e não ao nível da sub-rede, o que é muito eficaz para bloquear ataques Este/Oeste.
• Esta arquitetura reduz drasticamente a superfície de ataque global. A rede permite apenas a conectividade mínima necessária e contém apenas as sub-redes e tabelas de encaminhamento mínimas necessárias para permitir o acesso. Essencialmente, adaptámos a rede à aplicação. Na verdade, a rede só foi concebida depois de a pilha de aplicações ter sido arquitetada.
• Este é um exemplo muito simples de um pequeno site, mas os princípios podem aplicar-se a arquiteturas muito maiores, com um maior número de camadas, balanceadores de carga internos, API Gateways e componentes PaaS.

Como pode ver, dispõe de enorme flexibilidade ao utilizar as construções de rede da nuvem. Finalmente tem a possibilidade de construir a rede de que a aplicação precisa, em vez de adaptar a aplicação à rede que tem. Mas com esta flexibilidade vem também a possibilidade de configurar as coisas incorretamente e expor grandes porções da sua infraestrutura à Internet pública. Por isso, recomendamos sempre que monitorize a sua postura de segurança na nuvem e imponha as melhores práticas com uma plataforma de operações de segurança na nuvem (como a oferecida pela DisruptOps).