A ilusão da Falsa Resiliência - 9 Falácias da Arquitetura de Soluções
Publicado em 25 de abril de 2021
Desde criança aprendemos que a força de uma corrente é determinada por seu elo mais fraco, mas as vezes parecemos (queremos?) acreditar que alguns elos dourados - Microserviços, Kubernetes, Mensageria, NoSQL, etc. - farão toda diferença.
Quando trabalhamos com segurança da informação esse assunto é recorrente. Estamos sempre falando de riscos, vulnerabilidades e ameaças. Identificamos, mensuramos, avaliamos, mitigamos, etc.
Destes três itens - riscos, vulnerabilidades e ameaças - um deles foge ao nosso controle.
Podemos identificar e nos antecipar a ameaças, mas não controlá-las.
"Não dá para combinar com os russos"
Ameaças sempre existirão: terremotos, enchentes, epidemias, greve, blackout, terrorismo, etc.
Na arquitetura de soluções e software não seria diferente.
A resiliência de uma solução é caracterizada não apenas por sua capacidade de se recuperar após uma falha, mas principalmente por sua sua forma de lidar com intempéries.
Não adianta ser "disruptivo", deslanchar nas buzzword´s, utilizar as ferramentas mais modernas do mercado, se a solução como um todo é altamente acoplada e dependente de pontos centralizados, como bancos de dados, serviço de mensageria, cache, identity server, resource´s, etc.
Neste cenário, já vi uma aplicação inteira cair em decorrência do microserviço de idiomas que saiu do ar, e o site não tinha um idioma padrão, muito menos cache de idioma em algum lugar.
Chamo isso carinhosamente de "Aquíles Architecture". Poderosa, imponente, Brad Pitti, mas com uma vulnerabilidade grave.
Figura de Aquiles com Flecha no Calcanhar e diagrama com cluster kubernates com várias aplicações dependendo de um aplicativo externo
Na década de 90 duas grandes referencias da arquiteturas de soluções - Peter Deutsch e James Gosling - elencaram uma série de falácias, que muitas vezes assumimos como verdadeiras, relacionadas a qualidade da rede, latência e segurança .
Seguindo esta proposta, relaciono aqui, baseado em vivências, 9 falácias da arquitetura de soluções que considero comuns no dia a dia:
- Ninguém terá acesso ao código fonte pra saber dessa(s) vulnerabilidade(s);
- Ninguém vai automatizar as ações no meu site;
- Ninguém vai solicitar dados de um período e/ou volume tão grande;
- O serviço de mensageria aguenta sim;
- Se a alteração tiver algum impacto os testes vão identificar;
- Se o servidor/cluster/serviço/pod cair o outro sobe;
- Os patchs de atualização já chegam homologados;
- O firewall e/ou antivírus identificaria se algo acontecesse;
- O Cliente deve ter pensado "nisso";
Tendo estes itens em mente, procure se antecipar:
- Desenvolva e/ou oriente os desenvolvedores a pensarem que atacantes terão sim acesso ao código fonte;
- Use API Gateways, limite o número de requisições por minuto e/ou cliente, assim como recursos de cache e circuit breaks;
- Preveja o overload da aplicação; Descubra o que acontece se o sistema for estressado;
- Estresse o serviço de mensageria para testar e ajustar sua resiliência;
- Faça testes de disaster recovery;
- Homologue tudo que for possível;
- Não acredite que segurança e resiliência é responsabilidade de uma camada da solução, como firewall, cluster, antivírus, etc. Tenha uma visão holística;
- Tenha monitoramento;
- Teste seu monitoramento!
Não acredite que seu cliente pensou em tudo: Segurança, LGPD, resiliência, etc.
Tenha um plano! Sempre tenha uma plano! Um homem (ou mulher) sem um plano é um animal indefeso, um animal desprotegido; Tenha um plano de resposta a incidentes e saiba como usá-lo.
Se antecipe. Preveja. Planeje. Treine.
Tenha em mente que estes requisitos não serão requisitados diretamente pelo cliente. Os Product Owner não são obrigados a saber o que é um circuit breaker e muito menos vão se lembrar disso quando solicitarem uma solução para atender o negócio.
Lembrem-se das aulas de levantamento de requisitos. Entendam o que são requisitos funcionais e não funcionais. Agregue os não funcionais a estimativa.
E seja feliz.
