Considerações práticas sobre a nuvem: segurança

Computar na nuvem pode ser barato, mas não é gratuito.

A grande maioria dos aplicativos hoje são entregues via HTTP seguro. Isso significa TLS ou o cada vez mais desaprovado SSL. Significa criptografia, que tradicionalmente tem sido traduzido como problemas de desempenho.

Graças aos avanços da tecnologia, as CPUs são incrivelmente rápidas hoje em dia e muitos hardwares do cliente (e do lado do servidor) integram nativamente o que antes era hardware criptográfico especializado. O que isso significa é que, em uma base por conexão, a velocidade não é um problema tão grande para criptografia individualmente como era antes.

Mas isso não significa que a criptografia não seja uma fonte de desempenho e despesa operacional. 

A maioria dos argumentos que rejeitam o argumento contra a criptografia como uma fonte significativa de problemas de desempenho são baseados em cenários simples que envolvem um cliente e um servidor. Esse é um processo de criptografia e um processo de descriptografia. E em tais cenários, os pessimistas estão, em sua maioria, certos. A latência introduzida pela criptografia e descriptografia é mínima e normalmente é menos preocupante do que a sobrecarga relacionada ao TCP e à rede.

Mas os aplicativos de hoje não são compostos de um único ponto de extremidade. Existem vários intermediários e proxies pelos quais uma mensagem deve viajar antes que esse "único ponto final" seja encontrado. Eles são segurança e controle de acesso, balanceamento de carga e pontos de extremidade de roteamento. Cada um precisa inspecionar a mensagem — de forma clara — para executar sua função designada na dança complexa que é o caminho de dados moderno.

É aqui que o argumento de que a criptografia não é tão cara começa a desmoronar. Por si só, um único ponto final introduz muito pouco atraso. Mas quando repetidos diversas vezes em cada ponto final no caminho de dados, esses atrasos individuais se somam a algo mais perceptível e, particularmente no caso da nuvem pública, operacionalmente caro.

A criptografia é naturalmente um processo computacionalmente caro. Isso significa que são necessários muito mais ciclos de CPU para criptografar ou descriptografar uma mensagem do que para executar a lógica de negócios. Na nuvem, os ciclos da CPU são análogos ao dinheiro gasto. Em geral, é um custo aceito porque o objetivo é transferir custos de capital para despesas operacionais.

Mas os custos começam a aumentar se você tiver que descriptografar e criptografar uma mensagem várias vezes. Você está efetivamente pagando pelo mesmo processo criptográfico várias vezes. O que poderia custar apenas um centavo quando executado uma vez, de repente custa cinco centavos quando executado cinco vezes. Fazendo as contas das centenas de milhares de transações ao longo de um dia (ou uma hora), os custos resultantes são impressionantes.

Lembre-se também de que cada ciclo de CPU consumido pelo processamento criptográfico é um ciclo de CPU não gasto em lógica de negócios. Isso significa escalar mais cedo do que você gostaria, o que gera ainda mais custos, pois cada instância adicional é lançada para lidar com a carga.

Basta dizer que "SSL em todos os lugares" não deve resultar em arquiteturas de "descriptografia em todos os lugares" na nuvem.

Decifrar uma vez

Para reduzir os custos e maximizar a eficácia das CPUs pelas quais você está pagando, vale a pena investir tempo para projetar sua arquitetura baseada em nuvem com base no princípio de "descriptografar uma vez". "Descriptografar uma vez" significa que você deve minimizar o número de pontos de extremidade no caminho de dados que devem descriptografar e criptografar novamente as mensagens em trânsito.

Fazer isso exige premeditação e consideração cuidadosa dos dezesseis serviços de aplicativos diferentes que você está usando para proteger e dimensionar aplicativos hoje. Se você não estiver sujeito a regulamentações ou requisitos que exijam criptografia de ponta a ponta, projete seu caminho de dados de forma que as mensagens sejam descriptografadas o mais cedo possível para evitar ciclos adicionais desperdiçados em descriptografias posteriores. Se você precisar manter a criptografia de ponta a ponta, a combinação de serviços, sempre que possível, proporcionará o uso mais eficiente dos recursos de computação.

Combinar os serviços que você pode (por exemplo, balanceamento de carga com firewall de aplicativo da web) em uma única plataforma significa reduzir o número de vezes que você precisa descriptografar mensagens em trânsito. Ele tem a vantagem adicional de reduzir também o número de conexões e o tempo na rede, o que se traduz em benefícios de desempenho para usuários e consumidores. Mas a economia real está nos ciclos de CPU que não são gastos em descriptografia e recriptografia repetidas. 

Pode parecer perda de tempo considerar o impacto da criptografia e descriptografia para um aplicativo pouco usado hoje em dia. Os centavos certamente não cobrem o custo do esforço. Mas à medida que os aplicativos crescem, se expandem e sobrevivem ao longo do tempo, esses centavos vão se acumulando em quantias impactantes. Sem mencionar que, assim como os centavos, os microssegundos se somam. Ao considerar o impacto da criptografia em todo o caminho de dados, você pode obter benefícios a longo prazo para os usuários e para a empresa.