O outono chegou no quintal, a utopia tecnológica é violenta. A tecnologia está avançando. Carregamos no bolso um computador cujo poder de computação é centenas de milhões de vezes maior que o poder dos computadores que controlavam os vôos para a lua. Com a ajuda do Youtube VR, podemos nadar no oceano com água-viva e baleias, e os robôs há muito exploram os horizontes sem vida de planetas frios.
Ao mesmo tempo, engenheiros e especialistas em serviços de TI, desenvolvedores e seus inúmeros colegas se dividem em dois campos: aqueles que criam novas soluções (software, estratégias, sistemas de informação) e aqueles que os entendem.
Entre no ecossistema de desenvolvimento de aplicativos e no método de uso de microsserviços. Até recentemente, era um incompreensível, fechado de olhares indiscretos, uma técnica fundamentalmente nova. Hoje, porém, depois de apenas alguns anos, as grandes e médias empresas já estão usando com confiança essa abordagem em seu próprio ambiente de desenvolvimento. Como ele é? Não usaremos as definições "clássicas", mas contaremos com nossas próprias palavras.
Arquitetura de microsserviço. Contentores
Microsserviços é um método no qual a funcionalidade de um sistema é dividida em muitos serviços pequenos e cada um deles executa uma tarefa a partir de uma funcionalidade complexa. Um atua como um servidor web, o outro como um banco de dados, o terceiro está ocupado com outra coisa, etc. Entre todos esses microsserviços, a interação de rede é estabelecida e os recursos necessários são alocados. Um exemplo engraçado e não menos óbvio de tal conceito é o sistema de pedir e emitir o almoço em lanchonetes.
O cliente (usuário) cria um novo pedido usando o terminal ou recepção (servidor web), transfere dados sobre o número de hambúrgueres de queijo, batatas e o tipo de refrigerante em seu almoço (preenche o banco de dados), efetua um pagamento, após o qual os dados são transferidos para a cozinha, onde parte os funcionários fritam batatas (serviço de cozinha) e a outra parte espalha comida e derrama refrigerante (serviço de coleta). Em seguida, o pedido coletado é transferido para o contador emissor (serviço emissor), onde o cliente mostra um cheque com o número do pedido (há até verificação!), E eles almoçam. Cada uma das unidades de processo, neste caso, está ocupada com uma tarefa e, no entanto, trabalha com rapidez e facilidade, de acordo com um algoritmo estabelecido. Você deve admitir que seria tolice esperar que, na recepção, você beba refrigerante mais rápido do que na cozinha, ou que o funcionário que frita os hambúrgueres possa aceitar o pagamento pelo seu pedido. No entanto, se o sistema for devidamente depurado e os processos prosseguirem conforme o esperado, tudo funcionará de maneira rápida e eficiente.
Em relação à arquitetura de microsserviço, vale ressaltar um ponto importante - seu ambiente de execução. Hoje, uma opção generalizada são os contêineres (oi, Docker). Um recurso dos contêineres é a idéia de incluir neles todo o ambiente necessário, começando com uma imagem leve do sistema operacional, pacotes instalados, estruturas e bibliotecas carregadas e terminando com o próprio aplicativo. Como isso é útil? Pelo menos o fato de o desenvolvedor não conseguir descartar a explicação "Tudo funciona no meu computador" quando você o recebe com uma mensagem de que o aplicativo não está funcionando.
Os contêineres permitem criar aplicativos, agrupá-los com todo o ambiente em uma imagem pronta de um sistema leve e não se preocupar mais com os problemas associados ao trabalho em vários ambientes. Precisa implantar o aplicativo em outro servidor? Lançamos uma imagem de trabalho com ela no contêiner - e tudo funciona.
Em um sistema de informações criado usando contêineres, você não precisa mais se preocupar com as versões de software no ambiente em que os aplicativos estão sendo executados, e com os processos de entrega contínua implementados, você também precisa entregar código etc. A ideia de um contêiner implica que o próprio desenvolvimento o aplicativo é executado no mesmo ambiente de contêiner e, como o microsserviço está fechado, não importa para qual sistema operacional ou com quais pacotes instalados ele trabalha nele. O aplicativo funciona porque foi criado para um ambiente de contêiner que não muda, independentemente do sistema ao redor do contêiner. Você não precisa mais instalar todo o software necessário por um tempo longo e tedioso, para estabelecer conexões, dependências e pacotes. Você não precisa migrar aplicativos manualmente ao alternar entre ambientes de desenvolvimento e implantação ou quando as capacidades do centro de computação aumentam. Um novo nível de abstração apareceu, ocupando o lugar entre o software final com seus usuários e o ambiente host (virtual ou bare-metal), no qual tudo isso funciona. Essa abordagem, devido à sua conveniência, está ganhando força constantemente e não vai desacelerar.
Muitas grandes organizações se esforçam para adotar as melhores técnicas para melhorar a eficiência dos negócios, seu desenvolvimento, escalabilidade e transformação, inclusive no contexto de sistemas de informação. Afinal, é precisamente para grandes empresas orientadas para o digital que estão interessadas principalmente em soluções voltadas para flexibilidade, escalabilidade e mobilidade, pois, ao mudar o setor, fica suscetível a dificuldades associadas à expansão, adaptação a um mercado em mudança, etc. não necessariamente sobre empresas de TI. No contexto das questões de CI / CD e sua segurança, empresas do setor público, grandes players do mercado financeiro, como bancos e até monopolistas de logística, recorrem à nossa organização. Em todos os casos, uma coisa os une - o uso de contêineres de uma forma ou de outra no desenvolvimento de aplicativos, serviços etc.
Os grandes negócios costumam ser comparados aos tubarões. Nesse caso, é difícil fazer uma comparação mais adequada. Você viu como os tubarões atacam cardumes de peixes? Você já reparou o quanto os peixes pequenos são mais manobráveis, mesmo que estejam em um grande rebanho? Quem reage mais nítido, mais manobrável e mais rápido - um tubarão ou uma pequena cavala? O mesmo acontece com as empresas do mercado como um todo. Obviamente, não levamos em conta a Microsoft ou a Apple naqueles dias em que cabem na garagem, são casos isolados. Mas, estatisticamente, o cenário é tal que as grandes empresas são capazes de ditar tendências e definir direções; no entanto, é mais fácil para as pequenas empresas se adaptarem e se adaptarem rapidamente. E grandes empresas também estão tentando aumentar a mobilidade e a flexibilidade de maneiras acessíveis.
Mas, como se costuma dizer, há uma nuance ... As grandes empresas na verdade não são um monólito. Eles consistem em muitos departamentos, com muitos departamentos, equipes, unidades e um grupo ainda maior de funcionários. E no contexto de sistemas de informação e desenvolvimento, em particular, as áreas de ação das equipes podem se sobrepor. E exatamente nessa junção, essas situações de conflito surgem entre os serviços de SI e os desenvolvedores. Ou seja, verifica-se que nem as grandes nem as médias empresas estão imunes a essas dificuldades.
Mais cedo ou mais tarde, ao usar contêineres, a organização terá uma pergunta. Isso pode acontecer no início de seu uso, ou talvez após algum incidente, como resultado da qual a empresa sofrerá perdas.
Como tornar os processos seguros?
De uma forma ou de outra, geralmente ouvimos essa pergunta e, junto com o cliente, pensamos na solução e procuramos maneiras adequadas. Como regra, uma organização, especialmente uma grande organização que implementou o CI / CD, consiste de especialistas inteligentes e experientes, incluindo aqueles em segurança da informação. Essas pessoas entendem por que precisam usar microsserviços, que problemas serão resolvidos e que novas dificuldades aparecerão. Portanto, eles tomam ações para a implementação e uso bem-sucedidos da tecnologia: preparar a infraestrutura, realizar auditorias, implantar sistemas, criar processos e coordenar os regulamentos internos.
No entanto, nem sempre é possível prever tudo, acompanhar tudo e monitorar tudo. Veja como, por exemplo, entender se a versão do servidor SQL no contêiner contém uma vulnerabilidade crítica? Manualmente? Vamos dizer. E se houver dezenas de contêineres? E centenas?
Como um especialista em segurança da informação pode ter certeza de que a imagem do SO base no contêiner com o aplicativo não contém uma exploração oculta? Verificar manualmente? E o que exatamente verificar, onde procurar? Em todas as dezenas e centenas de contêineres? E onde conseguir tanto tempo e recursos?
Com o desenvolvimento e a distribuição do CI / CD, a questão da segurança no ciclo de desenvolvimento tornou-se mais aguda. Afinal, você precisa ter certeza de que, pelo menos, em um nível aceitável de qualidade de imagem, precisa conhecer as vulnerabilidades de software e pacotes, o estado dos contêineres em funcionamento e se ações suspeitas ou obviamente ilegítimas estão ocorrendo neles. E se estamos falando especificamente sobre o ciclo de desenvolvimento, vale a pena ter ferramentas para garantir a segurança no próprio processo de desenvolvimento, em seu pipeline e não apenas em contêineres. E você também precisa ter controle sobre segredos, auditoria de registros, controle sobre a interação da rede e assim por diante. E aqui chegamos à questão principal.
Por que a segurança é necessária e quais são seus recursos no CI / CD?
Essencialmente, é um conjunto de práticas para garantir a segurança dentro e ao redor do ciclo de desenvolvimento. Ou seja, é o uso de software especial, o desenvolvimento de métodos e regulamentos e até a preparação de equipes (as equipes são a chave de tudo!) Para garantir a segurança. E um ponto importante: a introdução justificada de toda essa segurança no desenvolvimento, e não sair do ombro!
Aqui nós moramos com mais detalhes. A abordagem usual da segurança de TI em geral e do desenvolvimento em particular, que vem à mente, é baseada nos princípios de "Proibir / Restringir / Prevenir". De longe, o sistema de informações mais seguro é aquele que não funciona. Mas deve funcionar! E as pessoas que usam esse sistema também devem poder trabalhar com ele.
Há um conflito de interesses mencionado acima. O especialista em segurança da informação procura tornar o ambiente seguro e deseja ter controle completo sobre ele, o desenvolvedor deseja tornar o produto e deseja que ele aconteça de forma rápida e conveniente, e o engenheiro de TI torna o ambiente viável, tolerante a falhas e, juntamente com o desenvolvedor, se esforça para automatizar.
A proteção no CI / CD não se refere a software ou regulamentos, trata-se de trabalho em equipe e da incorporação do conceito de segurança no fluxo de desenvolvimento. Essa abordagem visa o envolvimento igual de todos os participantes no processo, a distribuição de áreas claras de responsabilidade, a automação, o monitoramento e a geração de relatórios transparentes. E o mais importante, implementar a segurança dentro do processo de desenvolvimento de aplicativos, de maneira que apareça nos estágios iniciais e não exija a alocação de recursos adicionais, tanto computacionais quanto humanos.
Vamos dar uma olhada em um exemplo. Suponha que uma das equipes de desenvolvimento crie um aplicativo, isso acontece em um meio de contêiner sob a supervisão de especialistas em segurança da informação, enquanto os gerentes de infraestrutura mantêm a saúde desse ambiente. No final do desenvolvimento, um aplicativo pronto aparece que entra em produção e começa a trabalhar lá, os clientes o usam - todos estão felizes. Mas, após algum tempo, uma séria vulnerabilidade é descoberta no contêiner com o aplicativo. Um especialista em segurança da informação registra essa vulnerabilidade e a repassa aos desenvolvedores para eliminação; eles, por sua vez, o corrigem com um patch, após o qual é necessário reescrever as dependências e atualizar alguns pacotes. Em seguida, a próxima versão do aplicativo é lançada.
O tempo gasto pelos especialistas em IS para localizar o problema, o tempo da equipe de desenvolvimento para corrigi-lo e um pouco do serviço de IS realizará uma segunda auditoria e encerrará o caso. Mas e se pudéssemos usar algum tipo de ferramenta e implementá-la no estágio de desenvolvimento? E se nosso aplicativo não fosse lançado no produto, sendo inadequado para o nível de segurança fornecido? E cada especialista envolvido no processo pôde ver quais ameaças foram encontradas em sua área de responsabilidade? Mas e se todo o processo também fosse automatizado, começando com a detecção e terminando com incidentes no rastreador de erros?
Esse é o objetivo de organizar o desenvolvimento e a implementação seguros. Que não era apenas seguro, mas também conveniente. A introdução de novos processos ou o uso de ferramentas adicionais devem simplificar as atividades, e não vice-versa.
Existem ferramentas e técnicas que permitem monitorar o status dos elementos necessários do sistema e estágios do processo de desenvolvimento e ajudar todas as partes envolvidas a acompanhar os eventos em sua área de responsabilidade. A ênfase aqui não está no software especializado, mas na interação das pessoas com o sistema e entre si. É mais conveniente para o desenvolvedor corrigir e testar o aplicativo dentro do contêiner de trabalho? Bem, deixe-o consertar. Ao mesmo tempo, o serviço de SI deseja garantir que não haja ações ilegítimas dentro do contêiner? Não tem problema, ela vai saber. A tarefa foi concluída e ninguém interferiu com ninguém no processo. Eficiência e racionalidade! E isso é possível se você aplicar as ferramentas de segurança da informação necessárias nos lugares certos no ambiente de desenvolvimento e revisar as regras de interação entre serviços e equipes. E então não exista utopia, mas você deve concordar que viver com os dois se tornará um pouco mais fácil.
Por que unir as mãos dos desenvolvedores e carregar o serviço IB com ele, se você pode criar processos para que o desenvolvedor faça o que pode (abnegado, exausto em êxtase com a perfeição de seu código), e o especialista em IB controlou esse processo (sem interferir, mas apenas compartilhando esse prazer de lado).
Segurança de contêineres. Vale a pena?
Somos contatados pelos clientes em estágios completamente diferentes e com experiência diferente em CI / CD. Havia grandes organizações que enfrentavam um backdoor não detectado no contêiner em produção, através do qual o acesso a dados importantes era obtido e os dados eram roubados. Como resultado, tornou-se óbvio que, em um sistema pesado e pesado, é muito difícil acompanhar e neutralizar preventivamente as ameaças em potencial.
Também houve pequenas empresas que recentemente utilizaram o CI / CD no desenvolvimento. Após analisar os processos nos pipelines, seus especialistas chegaram à conclusão de que as ferramentas de segurança da informação disponíveis cobrem um volume insuficiente de processos e existem locais perigosos pelos quais um ataque pode ocorrer mais cedo ou mais tarde. Talvez não agora, talvez mais tarde, ou talvez nunca. Mas se isso acontecer, o preço do erro será alto.
Nossos clientes compartilham preocupações, que na maioria dos casos se resumem ao próprio conceito de vencer as mãos de desenvolvedores, engenheiros e todos os envolvidos no processo ao tentar ir além do prazo. Às vezes, porém, é mais fácil e rápido e, em alguns casos, geralmente é o contrário. E, em seguida, o serviço de SI deve analisar violações pelos dedos. Mas somos a favor de um conceito diferente. Por que violar ou ignorar os regulamentos que foram escritos com tanta dor? Por que os serviços devem interferir entre si para realizar suas tarefas? Ao trabalhar com o cliente, iniciamos a comunicação com seus problemas. Eles estão sempre lá.
"Não procure um cliente, encontre um problema e ofereça uma solução - o cliente aparecerá por si mesmo."
Tendo ouvido o cliente, em regra, entendemos que problemas ele enfrenta. Pode haver dificuldades na interação da equipe, decisões malsucedidas no design do "pipeline", falta de recursos humanos e de computação e muito mais. Em nossa abordagem para a implementação de aprimoramentos de segurança na infraestrutura do cliente, somos guiados pelo desejo de ajudar a resolver seus problemas e conseguir isso de uma maneira que minimize a probabilidade de novos. Assim, é criada uma base para o futuro, não importa quem atenderá o sistema criado, muitos problemas devem ser previstos e resolvidos no início. Nos estágios iniciais, na maioria dos casos, as decisões acabam sendo mais baratas do que com altas cargas de trabalho em produção profunda.
Com base nisso, sugerimos começar com uma auditoria, que inclui não apenas o estado dos sistemas de informação e seus elementos, mas também um entendimento do componente do processo entre as equipes de desenvolvimento, a abordagem dos serviços de segurança da informação etc. Não se esqueça de que as pessoas são o fator mais importante, tanto em termos de ameaças quanto dos resultados do funcionamento do sistema. Uma auditoria é uma etapa necessária, como resultado de importantes falhas ou erros de cálculo do sistema nas interações que, juntamente com o cliente que tentamos resolver ou processar, podem ser revelados. É importante entender que o objetivo não é empilhar muitas soluções e produtos de software e não calar as vulnerabilidades descobertas por eles. Pelo contrário, é provável que haja um cenário em que a compra de produtos de software caros possa não ser necessária. Freqüentemente, o processo de aumentar a segurança em um ambiente de CI / CD pode ser alcançado com a ajuda dos recursos de segurança existentes da organização, integrados ao ambiente de contêiner (no orquestrador, por exemplo) e de terceiros. O importante não é tanto a quantidade ou a qualidade, como a aplicação correta.
Com base nos resultados da auditoria, torna-se possível criar um plano de trabalho, um roteiro com tarefas intermediárias explícitas e um objetivo final compreensível. Bem, tudo o mais é uma questão técnica. O planejamento adequado em qualquer empresa é uma parte importante da conclusão bem-sucedida.
É importante não se deixar levar demais e não esquecer por que tudo é feito. Ninguém tem a tarefa de criar um sistema insanamente protegido no qual nenhum contêiner é iniciado quando alguma ameaça é detectada nele ou nenhum aplicativo é implantado na produção se houver algum desvio do modelo protegido. Vale lembrar que a introdução ou o lançamento de ferramentas de proteção deve servir não apenas para aumentar a segurança, mas também por conveniência.
Por exemplo, um desses casos envolveu a introdução de software de proteção de contêiner e ambientes de orquestração. Parece que eles implementaram, configuraram, verificaram e viram todas as vulnerabilidades - e depois o longo processo de eliminação. No entanto, com essa abordagem, surgem problemas que foram discutidos no início. O serviço de segurança da informação possui uma ferramenta que permite bloquear muitas atividades em um ambiente de orquestração que, se usado incorretamente, causará mais danos do que benefícios. Os desenvolvedores estão atados porque o serviço de segurança da informação está diminuindo suas capacidades. Por exemplo, não é mais possível corrigir algo dentro do contêiner "quente" e, quando uma vulnerabilidade de pacote é detectada na imagem, o desenvolvedor está envolvido na burocracia regulatória. Como resultado, a solução para um problema que poderia ser eliminado durante o dia é adiada indefinidamente.
Para evitar tais situações, recomendamos que os processos sejam organizados de forma que o serviço de segurança da informação não se afaste do processo de desenvolvimento, como costuma ser o caso, mas participe dele. Certamente leva algum tempo, mas vale a pena depurar o processo, e a vida está realmente ficando mais fácil. Por exemplo, as ferramentas de IS permitem monitorar ameaças já no estágio de montagem dentro do pipeline de CI / CD, e o serviço de IS pode registrar isso. Ao mesmo tempo, as informações sobre ameaças em cada estágio da montagem podem ser transferidas automaticamente para a equipe ou especialista responsável por um estágio específico e, por sua vez, tomará as ações necessárias para eliminar a ameaça. E tudo isso acontece não sob a supervisão de um chicote, mas sob o monitoramento do serviço de SI.Por fim, o tempo gasto na correção de vulnerabilidades pode ser significativamente reduzido e, com isso, os custos de negócios, por exemplo, financeiros ou de reputação.Com qualquer dado inicial, nos esforçamos para formar uma abordagem para organizar e melhorar o nível de segurança do desenvolvimento de contêineres, focando não apenas no design e implementação de soluções específicas, mas também de olho nos recursos humanos. Cada participante do processo cumpre seu papel e, quanto mais conveniente, menor a interferência desnecessária, melhor o resultado final. E se você encontrar um equilíbrio entre a conveniência de todas as partes envolvidas, terá uma equipe muito eficaz. No futuro, é claro, é possível várias otimizações, aplicações ou aumentos na automação de alguns processos, delegação de tarefas etc. Mas a idéia principal permanece inalterada - uma revisão da segurança como tal. Separação de tarefas, monitoramento em vez de proibições irracionais e participação de todos em suas áreas de responsabilidade.E, claro, conveniência! A segurança pode ser conveniente.