Desafios de segurança de microsserviços e como lidar com eles

À medida que mais organizações se afastam do monólito em direção a arquiteturas mais distribuídas e baseadas em microsserviços: A segurança está sendo mantida? Embora algumas coisas tenham melhorado, os microsserviços ainda apresentam alguns desafios de segurança significativos que os desenvolvedores e arquitetos terão de enfrentar.

Nesta entrevista, Daniel Bryant, CTO da SpectoLabs e consultor técnico independente, fala sobre alguns dos desafios que surgem ao abordar a segurança de microsserviços e algumas das ferramentas e técnicas que você pode usar.

Em comparação com as arquiteturas mais tradicionais, que novos desafios os microsserviços introduziram em termos de segurança?

Daniel Bryant: Na abordagem tradicional, você tinha uma coisa. Então, se ela estava noiva, você estava em apuros. É como colocar todos os ovos na mesma cesta. O outro lado disso é que, quando você quebra coisas, de repente você tem que proteger muito mais coisas. A superfície de ataque é muito maior. Você não está mais fazendo coisas como endurecer as bordas e não vai olhar mais atrás disso.

O maior desafio agora é que cada desenvolvedor deve estar muito mais preocupado com a segurança. Há muito mais coisas, há muito mais superfície de ataque e há muita comunicação entre todas as coisas que são expostas.

Que tipos de ferramentas e técnicas são importantes para a segurança de microsserviços?

Bryant: Existem coisas como firewalls de aplicativos da web, [que são] muito populares. Muitas empresas com as quais trabalhei usam coisas como F5 e, na verdade, são firewalls F5. Cada vez mais, vemos mais firewalls de software, mesmo com a Amazon.

Isso é claramente uma prevenção, mas você também deve pensar na detecção. Portanto, o básico: log de tráfego de banda baixa, log de tráfego da web, log de acesso SSH [Secure Socket Shell]. [Em] qualquer servidor da web voltado para o público, se você olhar os logs, as pessoas estão constantemente testando as bordas. [Então], você quer ver [se é] apenas deste endereço IP ou apenas deste país ... você deseja fazer algum tipo de análise contínua de onde as coisas estão vindo.

[Além disso,] que ataques existem? Que vetores eles estão tentando sondar? Se você não estiver corrigindo seus sistemas, poderá ter sorte um dia. Portanto, você definitivamente precisa de detecção e precisa ter certeza de que tudo está corrigido. [As pessoas dirão:] 'Sim, gastamos todo esse dinheiro em rede e computação.' Tudo bem, mas não se esqueça do app. Se o aplicativo tem uma vulnerabilidade enorme, todo o resto é para nada. Leva apenas um ponto de entrada para alguém entrar e começar a causar danos.

Eu definitivamente acho que coisas como modelagem de ameaças [são] muito úteis também. Entenda como as ameaças funcionam, quais ameaças existem e modele como elas podem atacar seu sistema. E muitas vezes, parece-me, um efeito colateral de modelar as coisas corretamente abre meus olhos para as diferentes maneiras como as coisas acontecem. Então, se você começar a criar vetores de ataque, de repente pensa, 'Bem, estou realmente reforçando isso no aplicativo', e pode perceber que há uma falha enorme em seu sistema de e-mail ou algo assim.

OWASP [Open Web Application Security Project], eles são uma organização impressionante. Eles têm uma tonelada de ferramentas de diagnóstico ou de linguagem para verificar vulnerabilidades de dependência crítica. Portanto, se estou usando Java ou Maven, posso colocá-lo no meu Maven Palm. Se estou usando Ruby, posso colocá-lo em minhas joias.

Qual é a pergunta que todos deveriam se perguntar quando se trata de segurança de microsserviços?

Bryant: Como posso contribuir? Pergunte à sua equipe, pergunte à sua gestão, aos seus líderes: O que posso fazer? Qual é o meu trabalho em relação à nossa segurança? Tenho que seguir certos padrões? Devo verificar meu trabalho? Esses tipos de coisas são os mais críticos.

Eu realmente acredito que a segurança de microsserviços não é muito diferente da segurança tradicional. Como desenvolvedores, estamos levando cada vez mais ... Tenho que ser uma pessoa de operações além de desenvolvedor. Você sabe, front end, back end, todas essas coisas. Se você não tomar cuidado, você terá cerca de uma milha de largura e uma polegada de profundidade.

Mas, ao mesmo tempo, se você, como desenvolvedor, for muito bem informado sobre a pilha, mas não souber muito sobre segurança, é muito fácil deixar grandes lacunas. Se deixar algumas brechas de segurança enormes, isso é potencialmente muito ruim. Portanto, desenvolver consciência, modelar, documentar, compartilhar, comparecer a conferências, conversar com as pessoas, aprender tudo o que puder ... tudo isso é importante.

O que os especialistas ainda estão preocupados quando se trata de segurança de microsserviços? Aquilo que as pessoas ainda parecem não entender direito?

Bryant: Não está [especificamente] colado a microsserviços; é mais um caso de como o mundo está se tornando cada vez mais conectado. Existem coisas como o bitcoin [que são] cada vez mais atraentes para os atacantes atacarem agora.

Acho que, como indústria, não somos tão responsáveis ​​quanto deveríamos. Portanto, é mais um caso de que é apenas o fator humano novamente. Estamos prestando atenção suficiente a ele como desenvolvedores ou arquitetos? Estamos fazendo coisas como defesa em profundidade? Estamos fazendo coisas como auditoria e registro e, em seguida, verificando essas coisas novamente? Existem algumas coisas básicas, como termos de codificação, que, novamente, não fazemos.

Quando se trata de segurança, o que é melhor em uma arquitetura tradicional, como arquitetura orientada a serviços (SOA), em comparação com uma arquitetura de microsserviços distribuída?

Bryant: Não mudou muito do ponto de vista desde o início. A única coisa que eu diria [é], com SOA, tínhamos muito mais governo. SOA foi impulsionado pela lei do fornecedor ... [Eles] estavam dizendo, 'Você deve usar meu ESB [barramento de serviço corporativo] ou minha tecnologia [privada].' Havia muitas desvantagens nisso, mas uma das vantagens era que alguém o possuía. Então você tem esse ESB, essa coisa [gerenciar] todas as conexões dentro de seus serviços [e era] sua bunda na linha, basicamente. Então, eles realmente investiram em política e governança e todos esses tipos de coisas. Se algo desse errado, você sabia para quem ligar.

Considerando que nos dias de hoje estamos caminhando para tecnologias mais leves, mas você tem que assumir mais responsabilidade como desenvolvedor e arquiteto. Governo e política e o resto, por pior que fosse às vezes, havia uma vantagem nisso. É o mesmo com a política: quanto mais controle você tem, obviamente, menos liberdade você tem, mas é um equilíbrio que existe em algum lugar.

Como as equipes de DevOps podem trabalhar melhor com as equipes de segurança para garantir a segurança dos serviços?

Bryant: Toda a filosofia DevOps é reunir todos. Portanto, muitas das consultorias para as quais trabalhei realmente lidavam e incorporavam infosec [segurança da informação]; em uma organização clássica, eles são freqüentemente chamados de infosec. Traga-os para o projeto o quanto antes, porque geralmente são boas pessoas, mas não são consultados até que as coisas entrem em operação. Portanto, primeiro você precisa envolvê-los. Seu conhecimento é inestimável, portanto, envolvê-los mais cedo é ótimo