🐳 💇🏼 🚋 DevOps vs DevSecOps: como ficava em um banco 🚃 🚧 👨🏽

O banco terceiriza seus projetos para muitos contratados. "Estranhos" escrevem o código e depois transmitem os resultados de uma forma não muito conveniente. Especificamente, o processo ficou assim: eles transferiram um projeto que passou nos testes funcionais com eles e, em seguida, já foram testados no perímetro bancário para integração, carga e assim por diante. Muitas vezes, foi descoberto que os testes eram feyl. Então tudo voltou ao desenvolvedor externo. Como você pode imaginar, isso significou muito tempo para corrigir erros.

O banco decidiu que é possível e necessário arrastar o oleoduto inteiro para si mesmo "sob a asa", das confirmações até a liberação. Para que tudo seja consistente e esteja sob o controle das equipes responsáveis pelo produto no banco. Ou seja, como se o contratado externo simplesmente trabalhasse em algum lugar da próxima sala do escritório. Na pilha corporativa. Este é um devopa comum.

De onde veio Sec? A segurança do banco estabeleceu altas exigências sobre como um contratado externo pode trabalhar no segmento de rede, quem tem acesso, como e quem trabalha com o código. Só que o IB ainda não sabia que, quando os contratados trabalham fora, poucos padrões bancários são respeitados. E aqui em alguns dias todo mundo precisa começar a observá-los.

Uma simples revelação de que o contratado tem acesso total ao código do produto já virou seu mundo de cabeça para baixo.

Nesse momento, começou a história do DevSecOps, sobre a qual quero contar.

Qual banco tirou conclusões práticas dessa situação

Houve muita controvérsia sobre o fato de que tudo está sendo feito na esfera errada. Os desenvolvedores disseram que a segurança é ocupada apenas com tentativas de impedir o desenvolvimento e eles, como vigias, tentam proibir sem pensar. Por sua vez, os guardas de segurança hesitaram entre escolher entre os pontos de vista: “desenvolvedores criam vulnerabilidades em nosso circuito” e “desenvolvedores não criam vulnerabilidades, mas eles mesmos são”. O debate continuaria por muito tempo, se não fosse pelos novos requisitos do mercado e o surgimento do paradigma DevSecOps. Foi possível explicar que essa própria automação de processos, levando em consideração os requisitos de segurança da informação "prontos para uso", ajudará a todos a serem satisfeitos. No sentido de que as regras são escritas imediatamente e não mudam durante o jogo (o IS não proibirá algo inesperadamente), e os desenvolvedores mantêm o IS informado sobre tudo o que acontece (o IS não encontra algo de repente).Cada equipe é responsável pela segurança máxima, e não por alguns irmãos mais velhos abstratos.

, , « ».
, , .
- , . , . .

Ou seja, os contratados podem ser permitidos, mas você precisa torná-los segmentos separados. Para que eles não se arrastem para fora de algum tipo de infecção na infraestrutura do banco e não vejam mais do que o necessário. Bem, para que suas ações sejam registradas. DLP para proteção contra "sumidouros", tudo isso foi aplicado.

Em princípio, todos os bancos chegam mais cedo ou mais tarde. Em seguida, saímos da trilha batida e concordamos com os requisitos para ambientes em que "estrangeiros" trabalham. Apareceu um conjunto máximo de ferramentas de controle de acesso, verificadores de vulnerabilidades, análise antivírus em circuitos, montagens e testes. Isso é o que eles chamaram de DevSecOps.

De repente, ficou claro que, se antes essa segurança bancária do DevSecOps não tinha controle sobre o que estava acontecendo do lado do desenvolvedor, então, no novo paradigma, a segurança é controlada da mesma maneira que os eventos comuns na infraestrutura. Somente agora há alertas sobre montagens, controle de biblioteca e assim por diante.

Resta apenas transferir a equipe para um novo modelo. Bem, crie uma infraestrutura. Mas estas são pequenas coisas, é assim que se desenha uma coruja. Na verdade, ajudamos na infraestrutura e, nesse momento, os processos de desenvolvimento mudaram.

O que estava mudando

Eles decidiram implementá-lo em pequenas etapas, porque perceberam que muitos processos desmoronariam e muitos "forasteiros" talvez não pudessem suportar as novas condições de trabalho sob a supervisão de todos.

Primeiro, criamos equipes multifuncionais e aprendemos a organizar projetos levando em consideração novos requisitos. Em termos de discussão organizacional, quais processos. Acabou o pipeline de montagem com todos os responsáveis.

CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
Teste: Sonarqube, SoapUI, jMeter, Selênio: MF Fortify, Performance Center, MF UFT, Atascama.
Apresentação (relatórios, comunicação): Grafana, Kibana, Jira, Confluence, RocketChat.
Operações : Ansible, Zabbix, Prometheus, Elastic + Logstash, Gerente de Serviços MF, Jira, Confluence, MS Project.

Selecionou uma pilha:

Base de Conhecimento - Confluência Atlassiana;
Rastreador de tarefas - Atlassian Jira;
Repositório de artefatos - "Nexus";
Sistema de Integração Contínua - “Gitlab CI”;
Sistema de análise contínua - “SonarQube”;
Sistema de Análise de Segurança de Aplicativos - “Micro Focus Fortify”;
Sistema de comunicação - “GitLab Mattermost”;
Sistema de Gerenciamento de Configuração - “Ansible”;
Sistema de monitoramento - “ELK”, “TICK Stack” (“InfluxData”).

Eles começaram a criar uma equipe que estaria pronta para contratar empreiteiros. Chegou a conclusão de que existem várias coisas importantes:

. — . , .
, . — , .

Para dar o primeiro passo, você tinha que entender o que estava sendo feito. E tivemos que determinar como proceder para isso. Começamos ajudando a desenhar a arquitetura da solução de destino, tanto na infraestrutura quanto na automação de CI / CD. Então começamos a montar esse transportador. Precisávamos de uma infraestrutura, a mesma para todos, onde os mesmos transportadores funcionassem. Oferecemos opções com assentamentos, pensou o banco, depois decidimos o que e o que significa que será construído.

Além disso, a criação do circuito - instalação, configuração do software. Desenvolvimento de scripts para infraestrutura e gerenciamento de implantação. A seguir está a transição para o suporte ao pipeline.

Decidimos executar tudo no piloto. Curiosamente, durante a pilotagem, uma certa pilha apareceu no banco pela primeira vez. Entre outras coisas, um fornecedor doméstico de uma das soluções para um lançamento antecipado foi proposto para o volume do piloto. A segurança o conheceu durante a pilotagem, e isso deixou uma experiência inesquecível. Quando eles decidiram mudar, felizmente, a camada de infraestrutura foi substituída por uma solução nutanix que já estava no banco antes. Antes disso, era para a VDI e a reutilizávamos para serviços de infraestrutura. Em pequenos volumes, não se encaixava na economia, mas em grandes volumes tornou-se um excelente ambiente para desenvolvimento e teste.

O restante da pilha é mais ou menos familiar para todos. Ferramentas de automação na parte Ansible foram usadas e guardas de segurança trabalharam em estreita colaboração com elas. A pilha Atlassinovsky foi usada pelo banco antes do projeto. Ferramentas de segurança Fortinet - Foi proposto pelos próprios guardas de segurança. A estrutura de teste foi criada pelo banco, sem perguntas. As perguntas foram causadas pelo sistema de repositório, eu tive que me acostumar.

Os empreiteiros receberam uma nova pilha. Eles deram tempo para reescrever no GitlabCI e migrar o Jira para o segmento bancário e assim por diante.

Passo a passo

Etapa 1. Primeiro, usamos a solução de um fornecedor doméstico; o produto foi mudado para o segmento de rede DSO recém-criado. A plataforma foi selecionada por prazos de entrega, escalabilidade e recursos completos de automação. Testes realizados:

Possibilidade de gerenciamento flexível e totalmente automatizado da infraestrutura da plataforma de virtualização (rede, subsistema de disco, subsistema de recursos de computação).
Automação do gerenciamento do ciclo de vida de máquinas virtuais (modelagem, instantâneos, backups).

Após a instalação e configuração básica da plataforma, ela foi usada como um ponto de colocação dos subsistemas do segundo estágio (ferramentas DSO, linhas gerais de desenvolvimento do sistema de varejo). Os conjuntos necessários de pipelines foram criados - criando, excluindo, modificando e fazendo backup de máquinas virtuais. Esses pipelines foram usados como o primeiro estágio do processo de implantação.

Resultado - o equipamento fornecido não atende aos requisitos do banco para desempenho e tolerância a falhas. O DIT Bank decidiu criar um complexo baseado no PAC Nutanix.

Etapa 2. Pegamos a pilha que foi definida e escrevemos scripts para a instalação automatizada e a pós-configuração para todos os subsistemas, para que tudo fosse transferido do piloto para o circuito de destino o mais rápido possível. Todos os sistemas foram implantados em uma configuração tolerante a falhas (onde esse recurso não se limita às políticas de licença do fornecedor) e são conectados aos subsistemas para coletar métricas e eventos. O IB analisou o cumprimento de seus requisitos e deu luz verde.

Etapa 3 . Migração de todos os subsistemas e suas configurações para o novo PAC. Os scripts de automação da infraestrutura foram reescritos e a migração do subsistema DSO foi realizada em um modo totalmente automatizado. Os caminhos de desenvolvimento de SI foram recriados pelos pipelines da equipe de desenvolvimento.

Etapa 4. Automação da instalação do software aplicativo. Essas tarefas foram definidas pelos líderes de equipe de novas equipes.

Etapa 5. Operação.

Acesso remoto

As equipes de desenvolvimento solicitaram o máximo de flexibilidade no trabalho com o circuito, e o requisito de acesso remoto a partir de laptops pessoais foi colocado no início do projeto. O banco já tinha acesso remoto, mas não era adequado para desenvolvedores. O fato é que o esquema usou uma conexão do usuário com um VDI seguro. Isso era adequado para aqueles que tinham correspondência suficiente e um pacote de escritório no local de trabalho. Os desenvolvedores precisariam de clientes pesados, de alto desempenho, com muitos recursos. E, é claro, eles precisavam ser estáticos, pois a perda de uma sessão de usuário para quem trabalha com o VStudio (por exemplo) ou outro SDK é inaceitável. A organização de um grande número de VDIs estáticos espessos para todas as equipes de desenvolvimento aumentou muito o custo da solução VDI existente.

Decidimos trabalhar com acesso remoto diretamente aos recursos do segmento de desenvolvimento. Jira, Wiki, Gitlab, Nexus, stands de montagem e teste, infraestrutura virtual. Os guardas de segurança estabeleceram requisitos para que o acesso possa ser organizado apenas de acordo com o seguinte:

Utilizando as tecnologias já disponíveis no banco.
A infraestrutura não deve usar controladores de domínio existentes que armazenam registros de contas / objetos produtivos.
O acesso deve ser limitado apenas aos recursos exigidos por uma equipe específica (para que uma equipe de um produto não possa acessar os recursos de outra equipe).
Controle máximo sobre o RBAC nos sistemas.

Como resultado, um domínio separado foi criado para este segmento. Esse domínio abrigava todos os recursos do segmento de desenvolvimento, credenciais do usuário e infraestrutura. O ciclo de vida dos registros neste domínio é gerenciado usando o IDM existente no banco.

O acesso diretamente remoto foi organizado com base nos equipamentos bancários existentes. O controle de acesso foi dividido em grupos do AD, que correspondiam às regras nos contextos (um grupo de produtos = um grupo de regras).

Gerenciar modelos de VM

A velocidade de criação do circuito de montagem e teste é um dos principais KPIs definidos pelo chefe da unidade de desenvolvimento, porque a velocidade de preparação do ambiente afeta diretamente o tempo de execução geral do pipeline. Duas opções para preparar imagens básicas de VM foram consideradas. O primeiro é o tamanho mínimo da imagem, padrão para todos os produtos / sistemas, a conformidade máxima com as políticas do banco para as configurações. A segunda é uma imagem básica que contém o software / software pesado instalado, cujo tempo de instalação pode afetar bastante a velocidade do pipeline.

Os requisitos de infraestrutura e segurança também foram levados em consideração durante o desenvolvimento - mantendo as imagens atualizadas (patches, etc.), integração com o SIEM, configurações de segurança de acordo com os padrões adotados pelo banco.

Como resultado, decidiu-se usar imagens mínimas para minimizar o custo de mantê-las atualizadas. É muito mais fácil atualizar o sistema operacional base do que instalar patches em cada imagem para novas versões de software / software.

Com base nos resultados, uma lista foi compilada a partir do conjunto mínimo exigido de sistemas operacionais, cuja atualização é realizada pela equipe operacional, e os scripts do pipeline são totalmente responsáveis por atualizar o software / software e, se necessário, alterar a versão do software instalado é suficiente para transferir a tag desejada para o pipeline. Sim, isso requer que a equipe do produto desenvolva cenários de implantação mais complexos, mas reduz bastante o tempo de operação para oferecer suporte a imagens básicas, que podem cair no serviço em mais de cem imagens básicas da VM.

Acesso à internet

Outro obstáculo à segurança bancária foi o acesso do ambiente de desenvolvimento aos recursos da Internet. Além disso, esse acesso pode ser dividido em duas categorias:

Acesso à infraestrutura.
Acesso a desenvolvedores.

O acesso à infraestrutura foi organizado por meio da proxy de repositórios externos pelo Nexus. Ou seja, o acesso direto de máquinas virtuais não foi fornecido. Isso tornou possível o comprometimento com o IS, que era categoricamente contra fornecer qualquer acesso ao mundo externo a partir do segmento de desenvolvimento.

O acesso à Internet para desenvolvedores foi necessário por razões óbvias (stackoverflow). E, embora todas as equipes, como mencionado acima, tenham acesso remoto ao circuito, nem sempre é conveniente quando você não pode fazer ctrl + v no local de trabalho do desenvolvedor no banco no IDE.

Foi acordado com o SI que, inicialmente, na fase de teste, o acesso será fornecido por meio de um proxy do banco com base em uma lista branca. No final do projeto - o acesso será transferido para a lista negra. Grandes tabelas de acesso foram preparadas, indicando os principais recursos e repositórios que precisavam de acesso no início do projeto. A coordenação desses acessos levou um tempo decente, o que nos permitiu insistir na transição mais rápida para as listas negras.

resultados

O projeto terminou há pouco menos de um ano. Curiosamente, mas todos os contratados no horário mudaram para a nova pilha e ninguém saiu por causa da nova automação. IB não tem pressa em compartilhar críticas positivas, mas não se queixa, das quais podemos concluir que elas gostam. Os conflitos diminuíram, porque o EI novamente sente o controle, mas ao mesmo tempo não interfere nos processos de desenvolvimento. As equipes assumiram mais responsabilidade e, em geral, a atitude em relação à segurança da informação se tornou melhor. O banco entendeu que a transição para o DevSecOps era quase inevitável e, na minha opinião, foi feita de maneira mais gentil e correta.

Alexander Shubin, arquiteto de sistemas.

DevOps vs DevSecOps: como ficava em um banco