Escala na era da segurança em tudo

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Na WWDC (Worldwide Developers Conference) da Apple, em junho, a gigante dos dispositivos móveis anunciou que, a partir de 1º de janeiro de 2017, todos os aplicativos da App Store DEVEM (no sentido normativo de “MUST” das RFCs, para quem é da área de redes) usar o App Transport Security (ATS).

Basicamente, isso obriga os aplicativos a usar HTTPS em vez de HTTP.

Agora, isso significa que as pessoas têm apenas alguns meses para:

1. Atualizar seus aplicativos móveis
   Isso parece óbvio. Afinal, o requisito é que os aplicativos móveis no iOS usem HTTPS. Então, sim, tem isso.
2. Oferecer suporte a HTTPS no backend
   Isso pode não ser tão óbvio, mas o objetivo do HTTPS é proteger as comunicações, o que pressupõe o envolvimento de pelo menos duas partes. No caso de aplicativos móveis, a outra parte é algum tipo de endpoint (aplicativo, serviço ou gateway de API), seja no ambiente local ou na nuvem. Esse endpoint também precisa oferecer suporte a HTTPS.

É esse segundo requisito que é mais complexo, tanto do ponto de vista técnico quanto operacional, do que o primeiro, pois não se trata apenas de acionar um interruptor. É preciso gerenciar e distribuir certificados e chaves, realizar atualizações e alterar as configurações de servidores web e gateways de API que antes não ofereciam suporte a HTTPS. Talvez sejam necessárias mudanças significativas na infraestrutura (e na arquitetura) para viabilizar esse suporte. Além disso, há mudanças operacionais a serem feitas, como monitorar a validade dos certificados e substituí-los antes que expirem.

Escalar na era em que tudo precisa ser seguro não é apenas uma questão de capacidade, mas também de competência operacional. O impacto operacional de manter uma infraestrutura segura para aplicações não é trivial. Não se resume a marcar algumas caixas ou criar um novo arquivo de configuração.

1. Mudanças nos processos

Se você está “praticando DevOps” (ou mesmo que não esteja), precisa analisar o processo do seu pipeline de implantação e garantir que ele inclua os componentes necessários para oferecer suporte a HTTPS. Isso significa que chaves, certificados e configurações devem fazer parte do processo.

2. Mudanças de gerenciamento

Os certificados expiram. E, quando isso acontece, é uma Coisa Ruim™. A equipe de Operações precisa saber quando os certificados vão expirar e garantir que haja um processo para renová-los e, em seguida, implantá-los (o que é basicamente um GOTO nº 1 – Mudança de Processo).

3. Alterações de capacidade

Criptografia e descriptografia têm um custo computacional considerável. Embora não consumam tantos recursos quanto antes, as conexões seguras ainda exigem mais recursos do que as não seguras. Talvez você não perceba nenhuma diferença significativa em aplicativos com pouquíssimos usuários. No entanto, para aqueles que são muito utilizados (simultaneamente), será necessário avaliar a capacidade disponível para expansão. Isso inclui não apenas os servidores (virtuais ou físicos), mas também a infraestrutura, como gateways de API (ou dispositivos/sistemas que desempenham essa função) e, possivelmente, registros de serviços (caso você já utilize contêineres e microsserviços).

4. Mudanças arquiteturais

Uma conexão segura de ponta a ponta pode comprometer todos os serviços de segurança entre o usuário e o aplicativo, tornando-os praticamente inúteis para impedir que malware ou código malicioso chegue a aplicativos e serviços com acesso a dados confidenciais. A capacidade de interceptar conexões seguras e inspecioná-las — tanto na entrada (solicitação) quanto na saída (resposta) — é um componente importante de uma estratégia de segurança bem-sucedida. Podem ser necessárias mudanças arquitetônicas para garantir que a infraestrutura crítica de segurança continue tendo a visibilidade necessária para cumprir seu papel na prevenção de violações e infecções.

Uma arquitetura de duas camadas, na qual as conexões seguras são gerenciadas pela rede principal, pode aliviar grande parte das dificuldades operacionais associadas à dispersão de certificados e chaves por toda a infraestrutura de aplicativos. Isso ocorre porque a conexão segura pode ser encerrada na rede principal por um proxy seguro. A comunicação com os aplicativos de back-end pode continuar em texto simples, se desejado, ou ser criptografada novamente para manter a comunicação segura de ponta a ponta. Os dados não criptografados podem ser espelhados para soluções de segurança (como IDS/IPS) para inspeção adicional, preservando o investimento na infraestrutura existente. Isso significa ter um único local central onde os certificados e as chaves devem ser implantados, gerenciados e monitorados. Também proporciona um ponto estratégico no caminho de dados N-S, onde a interceptação e a inspeção podem ocorrer sem interferir nas comunicações entre dispositivo móvel <—> aplicativo.

Independentemente disso, o impacto em escala de uma abordagem de Proteger Tudo para aplicativos (móveis ou não) não é apenas uma questão de recursos computacionais, mas também operacional. E, embora a Apple certamente seja uma das forças por trás dessas mudanças, ela não é a única. Vale lembrar que, apesar da eliminação da exigência de SSL/TLS para HTTP/2 no padrão oficial, a comunidade de navegadores da web somente oferecerá suporte a HTTP/2 sobre SSL/TLS. Isso significa que, à medida que uma parcela maior da web migra de HTTP/1x para HTTP/2, a abordagem de Proteger Tudo simplesmente continuará ampliando seu alcance.

Esse avanço contínuo rumo à eliminação de qualquer tipo de comunicação não criptografada entre aplicativos e usuários (por imposição ou por funcionalidade) exigirá, de algumas organizações, mudanças significativas tanto nos processos quanto nos produtos.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie