Escala na era do Secure Everything

Na WWDC (World Wide Developer Conference) da Apple em junho, a magnata dos dispositivos móveis anunciou que, a partir de 1º de janeiro de 2017, todos os aplicativos na loja de aplicativos DEVEM (esse é o estilo RFC DEVE para os profissionais de rede que estão acompanhando) usar o App Transport Security (ATS).

Basicamente, ele força os aplicativos a usar HTTPS em vez de HTTP.

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

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

É esse segundo requisito que é mais complexo, técnica e operacionalmente, do que o primeiro, porque não é apenas uma questão de apertar um botão. Há gerenciamento de certificados e chaves, distribuição, atualizações, alterações nas configurações em servidores web e gateways de API que antes não suportavam HTTPS. Pode haver grandes mudanças na infraestrutura (e arquitetura) para dar suporte. E então há mudanças operacionais que precisam ser feitas, incluindo observar as expirações dos certificados e substituí-los.

Escalar em uma era de Segurança Total não é apenas uma questão de capacidade, mas de capacidade operacional. O impacto operacional no suporte de uma infraestrutura de aplicativo segura não é trivial. Não são apenas caixas de seleção ou um novo arquivo de configuração.

1. Mudanças de processo

Se você estiver “fazendo DevOps” (ou mesmo se não estiver), você precisa examinar seu processo de pipeline de implantação e certificar-se de que ele inclui os componentes necessários para dar suporte a HTTPS. Isso significa que chaves, certificados e configuração devem ser incluídos no processo.

2. Mudanças de gestão

Os certificados expiram. E quando o fazem é algo ruim™. As operações precisam saber quando os certificados irão expirar e garantir que haja um processo em vigor para renová-los e, então, implantá-los (que é basicamente GOTO #1 – Mudança de Processo).

3. Mudanças de capacidade

Criptografia e descriptografia não são baratas em termos de computação. Mesmo que não sejam tão gananciosas quanto costumavam ser, as conexões seguras ainda consomem mais recursos do que as inseguras. Você pode não ver nenhuma diferença perceptível em aplicativos com poucos usuários. Mas para aqueles que estão em uso intenso (simultaneamente), você precisará examinar qual capacidade está disponível para expansão. E não apenas servidores (virtuais ou físicos), mas a infraestrutura também. Isso inclui gateways de API (ou dispositivos/sistemas agindo como gateways de API) e, potencialmente, registros de serviço (se você já estiver usando contêineres e microsserviços).

4. Mudanças arquitetônicas

Uma conexão segura de ponta a ponta pode prejudicar 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 alcancem aplicativos e serviços que tenham 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. Mudanças arquitetônicas podem ser necessárias para garantir que a infraestrutura crítica de segurança continue tendo a visibilidade necessária para desempenhar sua função na prevenção de violações e infecções.

Uma arquitetura de duas camadas na qual conexões seguras são gerenciadas pela rede central pode aliviar muitos dos problemas operacionais associados à existência de certificados e chaves espalhados pela infraestrutura do aplicativo. Isso ocorre porque a conexão segura pode ser encerrada na rede principal por um proxy seguro. A comunicação com aplicativos de back-end pode continuar sendo em texto simples, se desejado, ou criptografada novamente para manter a comunicação segura de ponta a ponta. Dados não criptografados podem ser espelhados em soluções de segurança (como IDS/IPS) para inspeção posterior, mantendo o investimento na infraestrutura existente. Isso significa um local central no qual certificados e chaves devem ser implantados, gerenciados e monitorados. Ele também fornece um ponto estratégico no caminho de dados do NS onde a interceptação e a inspeção podem ocorrer sem interferir nas comunicações entre dispositivos móveis e aplicativos .

Independentemente disso, o impacto na escala de uma abordagem Secure Everything para aplicativos (móveis e outros) não é apenas uma questão de recursos de computação, mas também operacional. E embora a Apple certamente seja uma impulsionadora dessas mudanças, ela não é a única. Lembre-se de que, apesar da eliminação do requisito SSL/TLS para HTTP/2 do padrão oficial, a comunidade de navegadores da Web oferecerá suporte apenas a HTTP/2 sobre SSL/TLS. Isso significa que, à medida que mais e mais sites migram do HTTP/1x para o HTTP/2, o Secure Everything continuará expandindo seu alcance.

Essa marcha contínua em direção à eliminação de qualquer tipo de comunicação não criptografada entre aplicativos e usuários (por decreto ou recurso) exigirá, para algumas organizações, mudanças significativas nos processos e também nos produtos.