Atualmente, como parte da implementação da nova estratégia de desenvolvimento e transformação digital, a VTB está implementando ativamente o DevOps, integrando a prática de desenvolver software seguro no processo de engenharia, aumentando o nível de automação e otimizando os processos rotineiros de produção. O objetivo dessas mudanças pode ser formulado em três pontos principais: velocidade, confiabilidade e eficiência. Naturalmente, ao realizar essas transformações globais, torna-se importante realizar reuniões informais abertas, nas quais você pode compartilhar sua própria experiência, discutir as várias encruzilhadas e nuances da introdução de várias práticas de produção. Mitapas são um excelente formato para aumentar o engajamento geral, a conscientização e a troca de experiências, tanto com colegas do banco quanto com parceiros de outras empresas.
Por baixo do corte - o mais interessante da primeira reunião da VTB “DevSecOps: respostas práticas para perguntas não triviais”, realizada em novembro no site da WeWork. A reunião contou com a presença de mais de 200 especialistas.
Como tudo começou
Como você sabe, o VTB é o segundo banco na Rússia em termos de número de clientes, ativos e indicadores financeiros. Desde 2018, o banco, como parte da estratégia de desenvolvimento, começou a mudar ativamente seu curso tecnológico e decidiu uma transição gradual para o desenvolvimento interno de sistemas de TI. Antes disso, a maioria dos sistemas e soluções era fornecida pelos fornecedores. Agora, tornou-se importante melhorar a qualidade, a segurança e a velocidade das entregas, formando equipes internas e construindo nosso próprio processo de TI de produção. Tudo parece simples e claro: há casos, há soluções - pegue e implemente.
Mas, na realidade, tudo é muito mais complicado. Nesse caminho, o banco teve que enfrentar muitas dificuldades. Igor Shvakov, chefe do departamento de automação de processos de desenvolvimento VTB, falou sobre isso em seu relatório.
O principal desafio é a exclusividade do VTB em termos de TI. Historicamente, o banco se desenvolveu por meio da aquisição e integração de grandes players, cada um com sua própria arquitetura de TI, hardware, processos de negócios etc. Desde 2018, o VTB, o VTB24 e o Banco de Moscou tornaram-se um VTB com seu próprio TI exclusivo. infraestrutura heterogênea e isolada em algum lugar. Naturalmente, para realizar mudanças transformacionais, construir simultaneamente um negócio (como uma estratégia de negócios) e implementar o DevOps (e especialmente o DevSecOps) nessas condições é uma história não trivial.
A primeira dificuldade que surgiu no início é um grande número de fornecedores e, como conseqüência, uma competência própria restrita. Precisávamos transferir contratados externos que trabalhavam fora do perímetro para a infraestrutura e os processos do banco. A segunda dificuldade é que os clientes comerciais exigiam o desenvolvimento ativo dos sistemas de TI para garantir a obtenção de alto desempenho comercial. Portanto, tivemos que trabalhar em uma situação de crescente atividade transacional dos clientes e alta dependência de integração de sistemas.
Inicialmente, planejamos fazer a transição para os trilhos internos gradualmente: selecione sistemas e defina metas, depois prepare equipes e infraestrutura e, na última etapa, selecione ferramentas e configure o DevSecOps Pipeline. Mas, na realidade, tivemos que fazer tudo de uma só vez e, ao mesmo tempo, resolver os problemas que surgissem.
Experiência de replicação do sistema
Como não tínhamos a infraestrutura para o desenvolvimento interno, foi decidido virtualizar tudo e mudar para a arquitetura x86 para minimizar custos e despesas. Como resultado, uma plataforma de infraestrutura foi construída com base na solução hiperconvergente Nutanix já existente e transferimos todas as ferramentas de desenvolvimento para ela o máximo possível.
Mas o ferro é ferro, e as pessoas trabalham nele. Nesse sentido, surgiu a questão de como formar equipes. Decidimos focar nos seguintes relacionamentos: dois desenvolvedores internos devem ter um tecnólogo, uma equipe de 10 desenvolvedores deve ter um engenheiro de DevOps e dois testadores de automação. É isso que chegamos à nossa própria experiência, trabalhando com mais de duas dúzias de sistemas. E essa abordagem tem sido muito eficaz.
A próxima pergunta interessante é como transferir sistemas para o circuito bancário.
Como regra, o ciclo de conversão padrão de um sistema leva de 7 a 8 meses. É apresentado da seguinte forma.
- Durante os primeiros dois meses, há uma seleção de funcionários. Ao mesmo tempo, as relações contratuais com contratados externos são analisadas quanto à possibilidade de transferi-las para o trabalho no circuito bancário.
- No terceiro mês, a competência principal do sistema está sendo formada e a equipe do DevOps está sendo concluída em termos de desenvolvimento, configuração de pipeline e testes automatizados. Ao mesmo tempo, o acesso aos sistemas de informação para equipes externas é regulamentado e fornecido.
- O quarto mês - treinando a equipe e transferindo o código para o repositório do banco do fornecedor.
- Quinto - desenvolvimento conjunto pelas equipes do banco e um contratado externo, aprimorando o Pipeline e o lançamento das primeiras entregas nele.
- No sexto e sétimo meses, as revisões piloto passam por todo o processo já diretamente na infraestrutura do banco.
- Resultado - pelo sétimo mês, a equipe conjunta já está trabalhando no mesmo ciclo de desenvolvimento do banco.
A experiência mostra que, com essa abordagem, é possível organizar equipes bem coordenadas e implementar um grande número de projetos em um ano e meio. Em palavras, tudo é tranquilo, mas no processo de transição tivemos problemas. Um deles é um grande volume de equipes de um provedor externo. Por exemplo, a equipe de um dos fornecedores consistia em mais de 200 desenvolvedores. Agora, a maioria deles trabalha dentro de um circuito comum na infraestrutura bancária. E havia muitas nuances semelhantes.
No momento, o banco já possui mais de vinte equipes de desenvolvimento (mais de 500 desenvolvedores em período integral e externos), cada um dos quais utiliza seu próprio pipeline em termos de IC. Para a maioria desses comandos, a etapa do CD é implementada. Existem também vários sistemas que já utilizam entrega automática de alterações em circuitos industriais.
As abordagens implementadas tornaram possível construir um pipeline e transferir o desenvolvimento para o segmento interno, não apenas para novos sistemas com uma arquitetura flexível de microsserviços, mas também para um grande número de sistemas monolíticos complexos baseados em soluções “in a box” adaptadas às necessidades do banco.
Desde o início, não procuramos maneiras fáceis e provamos que, com as competências corretas dos funcionários, você pode implementar práticas de DevOps para qualquer sistema de qualquer complexidade.
Agora o processo está ganhando força, novos sistemas estão sendo adicionados, a pilha tecnológica é padronizada, estágios únicos do pipeline, relatórios, regras de trabalho. Além disso, a abordagem para replicar práticas para outras equipes e blocos do banco está mudando para um novo nível de maturidade, os processos estão sendo otimizados, as funções e competências necessárias nas equipes e a responsabilidade dos participantes é especificada. Em geral, o processo de replicação foi colocado nos trilhos e está sendo transformado desde a inicialização dentro de um grande banco em uma solução corporativa de alta tecnologia. Esse caminho foi coberto em pouco mais de um ano e meio desde o momento da instalação do ferro no data center até a implementação das alterações no modo automático no circuito industrial ou pré-industrial.
Armadilhas
Como parte da nova estratégia da VTB, a transição para as práticas do DevSecOps foi apontada como uma das correntes estratégicas no nível do banco. Alexander Kalabukhov, chefe do Centro de Práticas de Engenharia do Departamento de Desenvolvimento de Sistemas de Produção de TI e Manutenção VTB, falou sobre isso em seu relatório.
Foi decidido transformar os serviços envolvidos no desenvolvimento, teste e operação em equipes multifuncionais que trabalham com a mesma funcionalidade comercial. As equipes incluem especialistas em arquitetura e desenvolvimento, tecnólogos, testadores e engenheiros de DevOps. Nos serviços centralizados, apenas o que resta possui competências únicas ou vive em um ritmo único (24/7) - administração aplicada e de sistema, segurança da informação.
Essa transição para equipes multifuncionais coloca novos requisitos para processos de gerenciamento de código (origem, teste, implantação etc.), gerenciamento de teste e desenvolvimento. Nos casos em que anteriormente eram permitidas lacunas no processo, elas agora estão se tornando obstáculos críticos e estamos melhorando nosso cenário de DevSecOps em termos de ferramentas e preenchendo lacunas no processo.
Falando em ferramentas. Um problema é que os bancos se enquadram em certos requisitos regulatórios relacionados ao sigilo bancário e outras restrições semelhantes. Qualquer sistema no banco passa no estágio de testes de aceitação para conformidade com os requisitos de segurança da informação, inclusive em termos de ferramentas de DevOps. Infelizmente, a maioria dos engenheiros de DevOps nunca trabalhou em um ambiente regulamentado tão difícil e geralmente conhece pouco sobre a auditoria dessas ferramentas, sobre como o acesso à rede e o acesso a dados devem ser limitados, o que fazer com os segredos trocados entre as ferramentas de DevOps etc.
A principal tarefa de criar proteção de dados dentro do banco é garantir que ninguém tenha acesso a todos os dados de uma só vez. É por isso que os desenvolvedores não podem desempenhar as funções de administradores de aplicativos e sistemas. Existem limitações semelhantes para os engenheiros do DevSec. Naturalmente, nenhum desses especialistas pode ser um administrador de segurança da informação. Depois de definidas todas as funções e o perímetro de sua autoridade, você pode incorporar o processo padrão para conceder direitos da ferramenta DevOps ao processo geral de concessão de direitos em um banco.
Um aspecto importante é a segurança da rede. Você deve cumprir a regra de que uma conexão só pode ser feita de circuitos mais confiáveis para menos confiáveis. Se o processo for realizado na direção oposta, é necessário fornecer lacunas na rede usando meios especiais. As conexões de rede devem ser estabelecidas com segurança e ainda criptografadas entre si. Caso contrário, vírus e outros softwares maliciosos podem entrar na cadeia, o que pode levar a vazamento de dados e incidentes em ambientes industriais.
Os problemas de segurança são influenciados pela maneira como os dados são organizados, porque existem vários ambientes de desenvolvimento e teste, é necessário ingressar no circuito do banco por meio de uma VPN para que os contratados possam trabalhar com seus laptops. Além disso, existem circuitos especiais em que o acesso a um círculo limitado de pessoas é permitido; os dados não devem ir além desses circuitos.
Portanto, apesar de toda a riqueza das ferramentas DevOps existentes, é necessário padronizá-las. Com a abordagem correta, a segurança da informação no banco introduz restrições ao processo de desenvolvimento e operação, mas não impede a introdução de novas tecnologias.
Cibersegurança acima de tudo
No contexto da transformação dos negócios e do menor tempo para o lançamento de novos produtos digitais no mercado, o principal desafio industrial é garantir a segurança da informação em todas as etapas do processo contínuo de produção. O tópico da integração de práticas seguras de desenvolvimento de software no DevOps foi objeto de um relatório de Yuri Sergeyev, sócio-gerente da Swordfish Security e líder da indústria do DevSecOps na Rússia.
A implementação do paradigma de segurança cibernética no DevOps é um processo bastante complicado, dentro do qual a camada de práticas de segurança envolve todo o ciclo de engenharia de produção. As práticas de segurança da informação são suportadas por uma pilha instrumental integrada em todas as etapas do processo.
As práticas necessárias de SI incluem:
- Controle de componentes de código aberto quando eles se enquadram no perímetro de desenvolvimento (Open Source Analysis, OSA);
- Análise de código estático (Static Application Security Testing, SAST);
- Monitoramento da composição de componentes de software (Software Composition Analysis, SCA);
- Todos os tipos de análise dinâmica (Teste de segurança de aplicativos dinâmicos, Teste de segurança de aplicativos interativos / DAST / IAST / Teste de segurança de aplicativos comportamentais, BAST);
- Análise de código binário e controle de composição de contêineres (Bytecode and Container Analysis, BCA);
- Implementação do WAF (Web Application Firewall).
Ao mesmo tempo, os aspectos mais importantes ao dimensionar e transformar processos do DevOps no paradigma derivado do DevSecOps são:
- Uso de bibliotecas, estruturas e componentes de software seguros por padrão durante o processo de desenvolvimento (Seguro por Padrão);
- Integração das práticas de tecnologia de SI no início do pipeline de CI / CD (abordagem Shift-Esquerda);
- Automação de todos os processos no conceito Tudo como um Código;
- Formação de uma comunidade de defensores da segurança, responsáveis pelas tarefas de segurança da informação nas equipes de produção e que são os guias de uma cultura de segurança de engenharia;
- Aplicação do modelo de maturidade DevSecOps, tanto para avaliar o processo existente quanto para a melhoria contínua;
- Garantir a transparência de todas as atividades de segurança para todos os participantes no processo de produção de engenharia.
Separadamente, vale enfatizar a importância da prática da orquestração do DevSecOps (Application Security Testing Orchestration, ASTO), que fornece integração de ponta a ponta da pilha de ferramentas de IS com ferramentas de desenvolvimento, gerenciamento automatizado do pipeline de segurança (pipelines), bem como a coleta, consolidação e análise de todos os dados de forma contínua. processo seguro de desenvolvimento de software. A prática da orquestração pode economizar significativamente recursos e reduzir em mais de 10 vezes o tempo total de implementação da iniciativa DevSecOps em ambientes complexos de engenharia heterogêneos.
Se falamos sobre a transformação como um todo, podemos distinguir os seguintes fatores-chave de sucesso:
- A introdução de uma ferramenta ou elemento separado do processo de segurança cibernética é, obviamente, uma etapa importante, mas em nenhum caso é uma bala de prata para abordar as questões de segurança do software desenvolvido em escala industrial. A chave do sucesso é apenas o aplicativo integrado de todo o conjunto de práticas de segurança da informação.
- A aplicação da prática da orquestração protegerá as equipes de engenharia e a equipe de segurança da informação do caos tecnológico da integração de instrumentos "até o joelho" e da automação descontrolada de "retalhos".
- A coleta de dados e a visualização subsequente das métricas permitirão gerenciar o processo de ponta a ponta, obter total transparência e também criar a base necessária para a aplicação das práticas de aprendizado de máquina no futuro.