Funcionar como um serviço (mais seguro)

Existem várias abordagens modernas para arquitetura e desenvolvimento de aplicativos que basicamente assumem a forma de "torná-lo menor e, portanto, mais eficiente".

Microsserviços e Função como Serviço (FaaS) dependem da noção de código altamente focado. Agora, embora seja verdade que a maioria das organizações não esteja decompondo aplicativos em centenas de microsserviços ou milhares de funções, elas estão gravitando em direção a esse design. Isso geralmente ocorre porque facilita o desenvolvimento ágil, pois uma equipe relativamente pequena pode projetar, desenvolver e refinar um serviço muito mais rapidamente do que um aplicativo grande e monolítico. Afinal, é muito mais fácil escrever e testar algo com 1.000 linhas de código do que um aplicativo maior com 100.000 linhas de código.

Mas há outro benefício interessante dos microsserviços e do FaaS que não está sendo tão divulgado quanto deveria: a segurança.

Há muitas discussões na Internet — e eu li um número significativo delas — que tentam definir a densidade de defeitos e vulnerabilidades "média do setor". Você encontrará uma ampla gama de estimativas, algumas baseadas em varreduras reais de código-fonte aberto e outras baseadas em números auto-relatados. A NASA, por exemplo, orgulhosamente alardeia sua densidade extremamente baixa de defeitos como uma das razões do sucesso do programa do ônibus espacial. Há também relatórios baseados em dados coletados objetivamente de empresas de segurança como a WhiteHat, mas seus números são focados em vulnerabilidades por aplicativo e não necessariamente por linhas de código.

Não há consenso real sobre a densidade de defeitos e vulnerabilidades, exceto que sim, existe uma.

No entanto, é lógico que quanto menos linhas de código você escrever, menos defeitos e vulnerabilidades provavelmente serão introduzidos. Tão importante quanto isso, quanto menos linhas de código você tiver que pesquisar para encontrar uma vulnerabilidade ou defeito, mais rápido você irá encontrá-lo e, presume-se, corrigi-lo.

Uma das razões pelas quais isso é verdade é o escopo. Se meu microsserviço ou função estiver focado na codificação de um aspecto da lógica de negócios, ele exigirá menos lógica e menos bibliotecas para implementar. Esse escopo menor significa menos chances de introduzir erros na lógica ou vulnerabilidades em bibliotecas (de terceiros ou não) necessárias para implementar essa lógica extra. Toda vez que você precisa incluir outro componente ou chamar outro serviço, você está introduzindo oportunidades para defeitos e vulnerabilidades.

Menos interfaces para a função ou microsserviço também contribuem para um código mais seguro. Cada interface (um ponto de entrada como uma chamada de API) introduz a possibilidade de uma vulnerabilidade porque você está manipulando a entrada do usuário. E a entrada do usuário, como todos sabemos, deve sempre ser tratada como suspeita e potencialmente maliciosa .

E se os microsserviços reduzem o potencial de vulnerabilidades e defeitos, reduzir ainda mais o escopo de uma função deve diminuir ainda mais a possibilidade.

Agora, isso não quer dizer que microsserviços e FaaS sejam inerentemente mais seguros do que suas contrapartes monolíticas e de três camadas. Código desleixado é código desleixado, não importa quantas linhas ele ocupe. Mas é verdade que ambas as arquiteturas se prestam a práticas de desenvolvimento e entrega que podem levar a um código mais seguro.

Manter os benefícios de segurança em mente ao avaliar ou implementar microsserviços e/ou FaaS pode realmente ajudar a evitar o inchaço do código, bem como a se defender contra a introdução de vulnerabilidades.