DevOps vs DevSecOps: como era em um banco

O banco terceiriza seus projetos para muitos empreiteiros. “Externos” escrevem o código e depois transmitem os resultados de uma forma não muito conveniente. Especificamente, o processo era assim: eles entregaram um projeto que passou nos testes funcionais com eles e depois foi testado dentro do perímetro bancário para integração, carga e assim por diante. Muitas vezes foi descoberto que os testes estavam falhando. Então tudo voltou para o desenvolvedor externo. Como você pode imaginar, isso significava longos prazos para correção de bugs.

O banco decidiu que era possível e necessário colocar todo o pipeline sob sua proteção, desde o commit até o release. Para que tudo fique uniforme e sob controle das equipes responsáveis ​​pelo produto no banco. Isto é, como se o contratante externo estivesse simplesmente trabalhando em algum lugar da sala ao lado do escritório. Na pilha corporativa. Este é um devops comum.

De onde veio o Sec? A segurança do banco exige muito de como um contratado externo pode trabalhar no segmento de rede, que acesso alguém tem, como e quem trabalha com o código. Só que o IB ainda não sabia que quando os empreiteiros trabalham fora, poucos padrões bancários são seguidos. E então, em alguns dias, todos precisarão começar a observá-los.

A simples revelação de que o contratante tinha acesso total ao código do produto já havia virado o seu mundo de cabeça para baixo.

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

Que conclusões práticas tirou o banco desta situação?

Houve muita polêmica sobre o fato de tudo estar sendo feito de forma errada. Os desenvolvedores disseram que a segurança só está ocupada tentando interferir no desenvolvimento e eles, como vigias, tentam proibir sem pensar. Por sua vez, os especialistas em segurança hesitaram entre escolher entre os pontos de vista: “os desenvolvedores criam vulnerabilidades no nosso circuito” e “os desenvolvedores não criam vulnerabilidades, mas são eles próprios”. A disputa teria continuado por muito tempo se não fossem as novas demandas do mercado e o surgimento do paradigma DevSecOps. Foi possível explicar que essa mesma automatização de processos levando em consideração os requisitos de segurança da informação “fora da caixa” ajudará todos a permanecerem satisfeitos. No sentido de que as regras são escritas imediatamente e não mudam durante o jogo (a segurança da informação não proibirá algo inesperado), e os desenvolvedores mantêm a segurança da informação informada sobre tudo o que acontece (a segurança da informação não encontra algo repentinamente) . Cada equipe também é responsável pela segurança final, e não por alguns irmãos mais velhos abstratos.

1. Como os funcionários externos já têm acesso ao código e a diversos sistemas internos, provavelmente será possível retirar dos documentos a exigência “o desenvolvimento deve ser realizado inteiramente na infraestrutura do banco”.
2. Por outro lado, precisamos de reforçar o controlo sobre o que está a acontecer.
3. O compromisso foi a criação de equipas multifuncionais, onde os colaboradores trabalham em estreita colaboração com pessoas externas. Nesse caso, é preciso garantir que a equipe trabalhe nas ferramentas dos servidores do banco. Do começo ao fim.

Ou seja, os empreiteiros podem ser autorizados a entrar, mas precisam receber segmentos separados. Para que não tragam algum tipo de infecção de fora para a infraestrutura do banco e para que não vejam mais do que o necessário. Bem, para que suas ações sejam registradas. DLP para proteção contra vazamentos, tudo isso incluso.

Em princípio, todos os bancos chegam a isso mais cedo ou mais tarde. Aqui seguimos o caminho mais conhecido e concordamos com os requisitos para ambientes onde “externos” funcionam. Surgiu uma gama máxima de ferramentas de controle de acesso, ferramentas de verificação de vulnerabilidades, análise antivírus em circuitos, montagens e testes. Isso é chamado de DevSecOps.

De repente, ficou claro que se antes do DevSecOps a segurança bancária não tinha controle sobre o que acontece do lado do desenvolvedor, então no novo paradigma a segurança é controlada da mesma forma que os eventos comuns na infraestrutura. Só agora existem alertas sobre montagens, controle de bibliotecas e assim por diante.

Resta transferir as equipes para o novo modelo. Bem, crie a infraestrutura. Mas isso são ninharias, é como desenhar uma coruja. Na verdade, ajudamos na infraestrutura e naquela época os processos de desenvolvimento estavam mudando.

O que mudou

Decidimos implementá-lo em pequenos passos, porque entendíamos que muitos processos iriam desmoronar e muitos “externos” poderiam não suportar as novas condições de trabalho sob a supervisão de todos.

Primeiro, criamos equipes multifuncionais e aprendemos a organizar projetos levando em conta novas exigências. No sentido organizacional discutimos quais processos. O resultado foi um diagrama do 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, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
• Apresentação (relatórios, comunicação): Grafana, Kibana, Jira, Confluence, RocketChat.
• Operações (manutenção, gerenciamento): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Pilha selecionada:

• Base de Conhecimento - Atlassian Confluence;
• 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 aplicações – “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 arrastar empreiteiros para dentro. Há uma percepção de que existem várias coisas importantes:

• Tudo deve ser unificado, pelo menos na transmissão do código. Porque havia tantos empreiteiros quanto tantos processos de desenvolvimento diferentes com peculiaridades próprias. Era preciso encaixar todos aproximadamente em um, mas com opções.
• Existem muitos empreiteiros e a criação manual de infra-estruturas não é adequada. Qualquer nova tarefa deve começar muito rapidamente – ou seja, a instância deve ser implantada quase instantaneamente para que os desenvolvedores tenham um conjunto de soluções para gerenciar seu pipeline.

Para dar o primeiro passo foi necessário entender o que estava sendo feito. E tivemos que determinar como chegar lá. Começamos ajudando a desenhar a arquitetura da solução alvo tanto em infraestrutura quanto em automação de CI/CD. Então começamos a montar esse transportador. Precisávamos de uma infraestrutura, igual para todos, onde funcionassem os mesmos transportadores. Oferecemos opções com cálculos, pensou o banco, depois decidiu o que seria construído e com quais recursos.

Em seguida vem a criação do circuito - instalação do software, configuração. Desenvolvimento de scripts para implantação e gerenciamento de infraestrutura. Em seguida vem a transição para o suporte do transportador.

Decidimos testar tudo no piloto. Curiosamente, durante o piloto, uma determinada pilha apareceu pela primeira vez no banco. Entre outras coisas, foi oferecido um fornecedor nacional de uma das soluções para o escopo do piloto para um lançamento rápido. A segurança o conheceu enquanto ele pilotava e isso deixou uma impressão inesquecível. Quando decidimos mudar, felizmente, a camada de infraestrutura foi substituída por uma solução Nutanix, que já estava no banco antes. Além disso, antes era para VDI, mas reutilizamos para serviços de infraestrutura. Em pequenos volumes não se enquadrava na economia, mas em grandes volumes tornou-se um excelente ambiente para desenvolvimento e testes.

O resto da pilha é mais ou menos familiar para todos. Foram usadas ferramentas de automação em Ansible, e especialistas em segurança trabalharam em estreita colaboração com elas. A pilha Atlassin foi usada pelo banco antes do projeto. Ferramentas de segurança Fortinet - foram propostas pelos próprios seguranças. A estrutura de teste foi criada pelo banco, sem perguntas. O sistema de repositório levantou questões; tive que me acostumar com isso.

Os empreiteiros receberam uma nova pilha. Eles nos deram tempo para reescrevê-lo para o GitlabCI, migrar o Jira para o segmento bancário e assim por diante.

Passo a passo

Passo 1. Primeiro, utilizamos uma solução de um fornecedor nacional, o produto foi conectado a um novo segmento de rede DSO criado. A plataforma foi escolhida pelo prazo de entrega, flexibilidade de escala e possibilidade de automação total. Testes realizados:

• Possibilidade de gestão flexível e totalmente automatizada da infraestrutura da plataforma de virtualização (rede, subsistema de disco, subsistema de recursos computacionais).
• Automação do gerenciamento do ciclo de vida da máquina virtual (modelagem, instantâneos, backups).

Após a instalação e configuração básica da plataforma, esta foi utilizada como ponto de colocação dos subsistemas da segunda etapa (ferramentas DSO, esboços de desenvolvimento de sistemas de varejo). Foram criados os conjuntos de pipelines necessários - criação, exclusão, modificação, backup de máquinas virtuais. Esses pipelines foram usados ​​como o primeiro estágio do processo de implantação.

O resultado é que o equipamento fornecido não atende aos requisitos do banco em termos de desempenho e tolerância a falhas. O DIT do banco decidiu criar um complexo baseado no pacote de software Nutanix.

estágio 2. Pegamos a pilha que foi definida e escrevemos scripts automatizados de instalação e pós-configuração para todos os subsistemas para que tudo fosse transferido do circuito piloto para o circuito alvo o mais rápido possível. Todos os sistemas foram implantados em uma configuração tolerante a falhas (onde esse recurso não é limitado pelas políticas de licenciamento do fornecedor) e conectados a subsistemas de métricas e coleta de eventos. O IB analisou o cumprimento dos seus requisitos e deu luz verde.

estágio 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 dos subsistemas DSO foi concluída de forma totalmente automatizada. Os contornos do desenvolvimento de IP foram recriados pelos pipelines das equipes de desenvolvimento.

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

Passo 5. Exploração.

Acesso remoto

As equipes de desenvolvimento solicitaram flexibilidade máxima no trabalho com o circuito, e a exigência de acesso remoto a partir de laptops pessoais foi levantada logo no início do projeto. O banco já tinha acesso remoto, mas não era adequado para desenvolvedores. O fato é que o esquema utilizava a conexão do usuário a um VDI protegido. Isso era adequado para quem precisava apenas de correspondência e um pacote de escritório no local de trabalho. Os desenvolvedores precisariam de clientes pesados, de alto desempenho e com muitos recursos. E claro, eles tinham que ser estáticos, pois a perda da sessão do usuário para quem trabalha com 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 no acesso remoto diretamente aos recursos do segmento de desenvolvimento. Jira, Wiki, Gitlab, Nexus, bancos de construção e teste, infraestrutura virtual. Os guardas de segurança exigiram que o acesso só possa ser fornecido sujeito ao seguinte:

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

Como resultado, um domínio separado foi criado para este segmento. Este domínio abrigou todos os recursos do segmento de desenvolvimento, tanto credenciais de usuário quanto infraestrutura. O ciclo de vida dos registos neste domínio é gerido através do IdM existente no banco.

O acesso remoto direto foi organizado com base nos equipamentos existentes no banco. O controle de acesso foi dividido em grupos AD, aos quais correspondiam regras de contexto (um grupo de produtos = um grupo de regras).

Gerenciamento de modelos de VM

A velocidade de criação de um loop de montagem e teste é um dos principais KPIs definidos pelo chefe da unidade de desenvolvimento, pois a velocidade de preparação do ambiente afeta diretamente o tempo geral de execução do pipeline. Foram consideradas duas opções para preparar imagens VM base. O primeiro são os tamanhos mínimos de imagem, padrão para todos os produtos do sistema, conformidade máxima com as políticas do banco em relação às configurações. A segunda é a imagem base, que contém um POPPO resistente instalado, cujo tempo de instalação pode influenciar bastante a velocidade de execução do pipeline.

Requisitos de infraestrutura e segurança também foram levados em consideração durante o desenvolvimento – manutenção de imagens atualizadas (patches, etc.), integração com SIEM, configurações de segurança conforme padrões do banco.

Como resultado, optou-se por utilizar o mínimo de imagens para minimizar o custo de mantê-las atualizadas. É muito mais fácil atualizar o sistema operacional base do que corrigir cada imagem para novas versões do POPPO.

Com base nos resultados, foi formada uma lista do conjunto mínimo necessário de sistemas operacionais, cuja atualização é realizada pela equipe de operações, e os scripts do pipeline são inteiramente responsáveis ​​por atualizar o software e, se necessário, alterar a versão do software instalado - basta transferir a tag necessária para o pipeline. Sim, isso exige que a equipe de produtos Devops tenha cenários de implantação mais complexos, mas reduz bastante o tempo operacional necessário para dar suporte a imagens base, que de outra forma poderiam exigir mais de cem imagens base de VM para serem mantidas.

Acesso à Internet

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

1. Acesso à infraestrutura.
2. Acesso do desenvolvedor.

O acesso à infraestrutura foi organizado por proxy de repositórios externos com Nexus. Ou seja, não foi fornecido acesso direto de máquinas virtuais. Isto permitiu chegar a um compromisso com a segurança da informação, que era categoricamente contra qualquer acesso ao mundo exterior por parte do segmento de desenvolvimento.

Os desenvolvedores precisavam de acesso à Internet por motivos óbvios (stackoverflow). E embora todos os comandos, como mencionado acima, tivessem acesso remoto ao circuito, nem sempre é conveniente quando não é possível fazer ctrl+v do local de trabalho do desenvolvedor no banco no IDE.

Foi alcançado um acordo com o IS que inicialmente, em fase de testes, o acesso será fornecido através de um proxy bancário baseado numa lista branca. Após a conclusão do projeto, o acesso será transferido para a lista negra. Foram elaboradas enormes tabelas de acesso, que indicavam os principais recursos e repositórios aos quais era necessário acesso no início do projeto. A coordenação destes acessos demorou bastante tempo, o que permitiu insistir na transição mais rápida possível para as listas negras.

Descobertas

O projeto terminou há pouco menos de um ano. Curiosamente, todos os empreiteiros mudaram para a nova pilha a tempo e ninguém saiu devido à nova automação. O IB não tem pressa em dar feedback positivo, mas também não reclama, pelo que podemos concluir que gostaram. Os conflitos diminuíram porque a segurança da informação novamente parece estar no controle, mas não interfere nos processos de desenvolvimento. As equipes receberam mais responsabilidades e a atitude geral em relação à segurança da informação melhorou. O banco entendeu que a transição para DevSecOps era quase inevitável e o fez, na minha opinião, da forma mais suave e correta.

Alexander Shubin, arquiteto de sistema.

Fonte: habr.com