Melhores práticas para implementação segura e compatível de aplicativos bancários em nuvem híbrida em IBM Cloud e Satellite – IBM Blog

Os clientes de serviços financeiros procuram cada vez mais modernizar as suas aplicações. Isto inclui a modernização do desenvolvimento e manutenção de código (ajudando com competências escassas e permitindo a inovação e novas tecnologias exigidas pelos utilizadores finais), bem como a melhoria da implementação e das operações, utilizando técnicas ágeis e DevSecOps.

Como parte de sua jornada de modernização, os clientes desejam ter flexibilidade para determinar qual é o melhor local de implantação “adequado à finalidade” para seus aplicativos. Isso pode ocorrer em qualquer um dos ambientes suportados pela Nuvem Híbrida (no local, em uma nuvem privada, em uma nuvem pública ou na borda). O IBM Cloud Satellite® atende a esse requisito, permitindo que aplicativos modernos e nativos da nuvem sejam executados em qualquer lugar que o cliente exigir, ao mesmo tempo em que mantém um plano de controle padrão e consistente para a administração de aplicativos na nuvem híbrida.

Além disso, muitas destas aplicações de serviços financeiros suportam cargas de trabalho regulamentadas, que exigem níveis rigorosos de segurança e conformidade, incluindo proteção Zero Trust das cargas de trabalho. O IBM Cloud for Financial Services atende a esse requisito, fornecendo uma estrutura completa de segurança e conformidade que pode ser usada para implementar e/ou modernizar aplicativos com segurança na nuvem híbrida.

Neste artigo, mostramos como implantar facilmente um aplicativo bancário em ambos IBM Cloud para Serviços Financeiros e Satélite, usando pipelines automatizados de CI/CD/CC de maneira comum e consistente. Isso requer um nível profundo de segurança e conformidade em todo o processo de construção e implantação.

Introdução a conceitos e produtos

O objetivo do IBM Cloud for Financial Services é fornecer segurança e conformidade para empresas de serviços financeiros. Isso é feito aproveitando os padrões da indústria, como NIST 800-53 e a experiência de mais de cem clientes de serviços financeiros que fazem parte do Financial Services Cloud Council. Ele fornece uma estrutura de controle que pode ser facilmente implementada usando Arquiteturas de Referência, Serviços de Nuvem Validados e ISVs, bem como os mais altos níveis de criptografia e conformidade contínua (CC) em toda a nuvem híbrida.

O IBM Cloud Satellite oferece uma verdadeira experiência de nuvem híbrida. O Satellite permite que cargas de trabalho sejam executadas em qualquer lugar sem comprometer a segurança. Um único painel garante a facilidade de ver todos os recursos em um painel. Para implantar aplicativos nesses ambientes variados, desenvolvemos um conjunto de conjuntos de ferramentas DevSecOps robustos para construir aplicativos, implantá-los em um local Satellite de maneira segura e consistente e monitorar o ambiente usando as melhores práticas de DevOps.

Neste projeto, utilizamos um aplicativo de originação de empréstimos que foi modernizado para usar Kubernetes e microsserviços. Para entregar este serviço, o aplicativo bancário emprega um ecossistema de aplicativos parceiros interoperando usando o BIAN estrutura.

Visão geral do aplicativo

A aplicação utilizada neste projeto é uma aplicação de originação de empréstimos desenvolvida como parte do BIAN sem núcleo Iniciativa 2.0. Um cliente obtém um empréstimo personalizado por meio de um canal online seguro oferecido por um banco. O aplicativo emprega um ecossistema de aplicativos de parceiros interoperando na arquitetura BIAN, que é implementada na IBM Cloud for Financial Services. A Iniciativa BIAN Coreless capacita as instituições financeiras a selecionar os melhores parceiros para ajudar a trazer novos serviços ao mercado de forma rápida e eficiente através das arquiteturas BIAN. Cada componente ou domínio de serviço BIAN é implementado por meio de um microsserviço, que é implementado em um cluster OCP na IBM Cloud.

Componentes de aplicação baseados em domínios de serviço BIAN

• Diretório de produtos: Mantém um diretório abrangente dos produtos e serviços do banco.

• Empréstimo ao Consumidor: trata do cumprimento de um produto de empréstimo ao consumidor. Isto inclui a configuração inicial do mecanismo de empréstimo e a conclusão de tarefas programadas e ad hoc de processamento de produtos.

• Processo/API de oferta ao cliente: orquestra o processamento de uma oferta de produto para um cliente novo ou estabelecido.

• Perfil de roteamento de grupo: Mantém um pequeno perfil de indicadores-chave para um cliente que é referenciado durante as interações com o cliente para facilitar decisões de roteamento, atendimento e cumprimento de produtos/serviços.

Visão geral do processo de implantação

Um fluxo de trabalho ágil de DevSecOps foi usado para concluir as implantações na nuvem híbrida. Os fluxos de trabalho DevSecOps concentram-se em um processo de entrega de software frequente e confiável. A metodologia é iterativa em vez de linear, o que permite que as equipes de DevOps escrevam código, integrem-no, executem testes, entreguem lançamentos e implantem alterações de forma colaborativa e em tempo real, mantendo a segurança e a conformidade sob controle.

A implementação do IBM Cloud for Financial Services foi obtida em um cluster de zona de destino seguro, e a implementação da infraestrutura também é automatizada usando política como código (terraform). O aplicativo é composto por vários componentes. Cada componente foi implantado usando seu próprio Integração contínua (CI), Entrega Contínua (CD) e Conformidade Contínua (CC) pipeline em um cluster RedHat OpenShift. Para conseguir a implantação no Satellite os pipelines CI/CC foram reutilizados e um novo pipeline CD foi criado.

Integração contínua

Cada componente da implementação do IBM Cloud tinha seu próprio pipeline de CI. Um conjunto de procedimentos e abordagens recomendados está incluído na cadeia de ferramentas de CI. Um scanner de código estático é usado para inspecionar o repositório do aplicativo em busca de segredos armazenados no código-fonte do aplicativo, bem como de quaisquer pacotes vulneráveis ​​usados ​​como dependências no código do aplicativo. Para cada commit do Git, uma imagem de contêiner é criada e uma tag é atribuída à imagem com base no número da compilação, carimbo de data/hora e ID do commit. Este sistema de etiquetagem garante a rastreabilidade da imagem. Antes de criar a imagem, o Dockerfile é testado. A imagem criada é salva em um registro de imagens privado. Os privilégios de acesso para a implantação do cluster de destino são configurados automaticamente usando tokens de API, que podem ser revogados. Uma verificação de vulnerabilidade de segurança é executada na imagem do contêiner. Uma assinatura Docker é aplicada após a conclusão bem-sucedida. A adição da tag de imagem criada atualiza instantaneamente o registro de implantação. O uso de um namespace explícito em um cluster serve ao propósito de isolar cada implantação. Qualquer código mesclado na ramificação especificada do repositório Git, expressamente para implantação no cluster Kubernetes, é construído, verificado e implementado automaticamente.

Os detalhes de cada imagem docker são armazenados em um repositório de inventário, que é explicado em detalhes na seção Implantação Contínua deste blog. Além disso, as evidências são coletadas ao longo de cada execução do pipeline. Esta evidência descreve quais tarefas foram realizadas na cadeia de ferramentas, como verificações de vulnerabilidades e testes unitários. Essas evidências são armazenadas em um repositório git e em um bucket de armazenamento de objetos em nuvem, para que possam ser auditadas, se necessário.

Reutilizamos as cadeias de ferramentas de CI atuais usadas para a implementação do IBM Cloud declarada acima para a implementação do Satellite. Como o aplicativo permaneceu inalterado, foi desnecessário reconstruir os pipelines de CI para a nova implantação.

Entrega Contínua

O inventário serve como fonte de verdade sobre quais artefatos são implantados em qual ambiente/região; isso é conseguido usando ramificações git para representar ambientes, com um pipeline de promoção atualizando ambientes em uma abordagem baseada em GitOps. Nas implantações anteriores, o inventário também hospedava arquivos de implantação; estes são os arquivos de recursos YAML do Kubernetes que descrevem cada componente. Esses arquivos de implantação seriam atualizados com os descritores de namespace corretos, juntamente com a versão mais recente da imagem Docker para cada componente.

No entanto, achamos essa abordagem difícil por alguns motivos. Do ponto de vista dos aplicativos, ter que alterar tantos valores de tags de imagem e namespaces usando ferramentas de substituição YAML (como YQ) era algo grosseiro e complicado. Para o próprio Satellite, estamos usando a estratégia de upload direto, com cada arquivo YAML fornecido contando como uma “versão”. Preferiríamos que uma versão correspondesse a toda a aplicação, e não apenas a um componente ou microsserviço.

Uma abordagem diferente era desejada, então reestruturamos o processo de implantação para usar um gráfico Helm. Isso nos permitiu parametrizar valores importantes, como namespaces e tags de imagem, e injetá-los no momento da implantação. O uso dessas variáveis ​​elimina grande parte da dificuldade associada à análise de arquivos YAML para um determinado valor. O gráfico do helm foi criado separadamente e armazenado no mesmo registro de contêiner que as imagens BIAN construídas. Atualmente estamos trabalhando para desenvolver um pipeline de CI específico para validação de gráficos de leme; isso irá limpar o gráfico, empacotá-lo, assiná-lo quanto à veracidade (isso seria verificado no momento da implantação) e armazenar o gráfico. Por enquanto, essas etapas são feitas manualmente para desenvolver o gráfico. Há um problema ao usar gráficos de leme e configurações do Satellite juntos: a funcionalidade do leme requer uma conexão direta com um cluster Kubernetes ou OpenShift para operar de forma mais eficaz, e o Satellite, é claro, não permitirá isso. Portanto, para resolver este problema, usamos o “modelo de leme” para gerar o gráfico formatado corretamente e, em seguida, passar o arquivo YAML resultante para a função de upload do Satellite. Essa função aproveita então a CLI do IBM Cloud Satellite para criar uma versão de configuração contendo o YAML do aplicativo. Existem algumas desvantagens aqui: não podemos usar algumas funcionalidades úteis que o Helm fornece, como a capacidade de rollback a uma versão anterior do gráfico e os testes que podem ser feitos para garantir que o aplicativo esteja funcionando corretamente. Porém, podemos usar o mecanismo de rollback do Satellite como substituto e usar seu versionamento como base para isso.

Conformidade Contínua

O pipeline CC é importante para a verificação contínua de artefatos e repositórios implantados. O valor aqui é encontrar vulnerabilidades recentemente relatadas que podem ter sido descobertas após a implantação do aplicativo. As últimas definições de vulnerabilidades de organizações como Snyk e os votos de Programa CVE são usados ​​para rastrear esses novos problemas. A cadeia de ferramentas CC executa um scanner de código estático em intervalos definidos pelo usuário nos repositórios de aplicativos fornecidos para detectar segredos no código-fonte do aplicativo e vulnerabilidades nas dependências do aplicativo.

O pipeline também verifica imagens de contêineres em busca de vulnerabilidades de segurança. Qualquer problema de incidente encontrado durante a verificação ou atualização é marcado com uma data de vencimento. A evidência é criada e armazenada no IBM Cloud Object Storage no final de cada execução que resume os detalhes da varredura.

Insights de DevOps é valioso para acompanhar os problemas e a postura geral de segurança do seu aplicativo. Esta ferramenta contém todas as métricas da cadeia de ferramentas anterior executada em todos os três sistemas: integração contínua, implantação e conformidade. Qualquer resultado de varredura ou teste é carregado nesse sistema e ao longo do tempo, você poderá observar como sua postura de segurança está evoluindo.

Obter CC em um ambiente de nuvem é significativo para setores altamente regulamentados, como serviços financeiros, que desejam proteger dados de clientes e aplicativos. No passado, esse processo era difícil e precisava ser feito manualmente, o que colocava as organizações em risco. Mas com Centro de Segurança e Conformidade da IBM Cloud, você pode adicionar verificações de conformidade automáticas e diárias ao seu ciclo de vida de desenvolvimento para ajudar a reduzir esse risco. Essas verificações incluem várias avaliações de conjuntos de ferramentas DevSecOps para garantir segurança e conformidade.

Com base em nossa experiência com este projeto e outros projetos semelhantes, criamos um conjunto de melhores práticas para ajudar as equipes a implementar soluções de nuvem híbrida para IBM Cloud for Financial Services e IBM Cloud Satellite:

• Integração contínua
  • Mantenha uma biblioteca de scripts comum para aplicativos semelhantes em diferentes cadeias de ferramentas. Este é o conjunto de instruções que determina o que seu conjunto de ferramentas de CI deve fazer. Por exemplo, o processo de construção de aplicativos NodeJS geralmente seguirá a mesma estrutura, portanto, faz sentido manter uma biblioteca de scripts em um repositório separado, ao qual as cadeias de ferramentas se referirão ao construir aplicativos. Isto permite uma abordagem consistente à CI, promove a reutilização e aumenta a capacidade de manutenção.
  • Alternativamente, as cadeias de ferramentas de CI podem ser reutilizadas para aplicações semelhantes com o uso de gatilhos; esses gatilhos separados podem ser usados ​​para especificar qual aplicativo será criado, onde está o código do aplicativo e outras personalizações.

• Entrega Contínua
  • Para aplicativos com vários componentes, mantenha um único inventário e, portanto, uma única cadeia de ferramentas de implantação para implantar todos os componentes listados no inventário. Isso evita muita repetição. Todos os arquivos de implantação YAML do Kubernetes têm o mesmo mecanismo de implantação, portanto, um conjunto de ferramentas único iterando sobre cada um deles é mais lógico do que manter vários conjuntos de ferramentas de CD, todos essencialmente fazendo a mesma coisa. A capacidade de manutenção aumentou e há menos trabalho a ser feito para implantar o aplicativo. Os gatilhos ainda podem ser usados ​​para implantar microsserviços individuais, se desejado.
  • Use gráficos Helm para aplicativos complexos de vários componentes. O uso do Helm no projeto BIAN facilitou muito a implantação. Os arquivos Kubernetes são escritos em YAML, e usar analisadores de texto baseados em bash é complicado se vários valores precisarem ser personalizados no momento da implantação. Helm simplifica isso usando variáveis, o que torna a substituição de valores muito mais eficaz. Além disso, o Helm oferece outros recursos, como controle de versão de todo o aplicativo, controle de versão de gráfico, armazenamento de registro de configuração de implantação e recursos de reversão em caso de falha. Embora a reversão não funcione em implantações específicas do Satellite, isso é atendido pelo versionamento de configuração do Satellite.
• Conformidade Contínua
  • Recomendamos fortemente a configuração de conjuntos de ferramentas CC como parte de sua infraestrutura para verificar continuamente códigos e artefatos em busca de vulnerabilidades recentemente expostas. Normalmente, essas verificações podem ser executadas todas as noites ou em qualquer horário adequado à sua aplicação e situação de segurança. Para acompanhar os problemas e a postura geral de segurança do seu aplicativo, sugerimos que você use o DevOps Insights.
  • Também recomendamos o uso do Centro de Segurança e Conformidade (SCC) para automatizar sua postura de segurança. O resumo de evidências gerado pelos pipelines pode ser carregado no SCC, onde cada entrada no resumo de evidências é tratada como um “fato” relacionado a uma tarefa concluída em uma cadeia de ferramentas, seja uma verificação de vulnerabilidade, teste de unidade ou outras coisas semelhantes . O SCC executará então testes de validação com base nas evidências para determinar se as melhores práticas relacionadas aos conjuntos de ferramentas estão sendo seguidas.
• Estoque
  • Conforme mencionado anteriormente, com a implantação contínua, é preferível manter um único inventário de aplicativos no qual todos os detalhes do seu microsserviço serão armazenados, junto com (se não estiver usando o Helm) os arquivos de implantação do Kubernetes. Isso permite uma única fonte de verdade sobre o estado de suas implantações; como as ramificações em seu inventário representam ambientes, a manutenção desses ambientes em vários repositórios de inventário pode se tornar complicada muito rapidamente.
• evidência
  • A abordagem aos repositórios de evidências deve ser tratada de forma diferente do inventário. Neste caso, é preferível um repositório de evidências por componente; se você combiná-los, as evidências armazenadas podem se tornar esmagadoras e difíceis de gerenciar. Localizar evidências específicas é muito mais eficiente se as evidências forem armazenadas em um repositório específico para um componente. Para implantação, um único armário de evidências é aceitável, pois é proveniente de uma única cadeia de ferramentas de implantação.
  • Recomendamos fortemente o armazenamento de evidências em um bucket de armazenamento de objetos na nuvem, bem como o uso da opção de repositório git padrão. Isso ocorre porque um bucket COS pode ser configurado para ser imutável, o que nos permite armazenar as evidências com segurança e sem possibilidade de adulteração, o que é muito importante no caso de trilhas de auditoria.        

Conclusão

Neste blog, apresentamos nossa experiência na implementação de uma aplicação bancária baseada em BIAN na nuvem híbrida, ou seja, usando pipelines DevSecOps para implementar a carga de trabalho tanto na IBM Cloud quanto em um ambiente Satellite. Discutimos os prós e os contras de diferentes abordagens e as melhores práticas que derivamos após passar por este projeto. Esperamos que isso possa ajudar outras equipes a alcançar sua jornada na nuvem híbrida com mais consistência e velocidade. Deixe-nos saber sua opinião.

Explore o que a IBM tem a oferecer hoje