Mejores prácticas para una implementación segura y compatible de aplicaciones bancarias en la nube híbrida en IBM Cloud y Satellite – Blog de IBM

Los clientes de servicios financieros buscan cada vez más modernizar sus aplicaciones. Esto incluye la modernización del desarrollo y mantenimiento del código (ayudando con habilidades escasas y permitiendo la innovación y nuevas tecnologías requeridas por los usuarios finales), así como la mejora del despliegue y las operaciones, utilizando técnicas ágiles y DevSecOps.

Como parte de su viaje de modernización, los clientes quieren tener flexibilidad para determinar cuál es la mejor ubicación de implementación "adecuada para su propósito" para sus aplicaciones. Esto puede ser en cualquiera de los entornos que admite la nube híbrida (on premise, en una nube privada, en una nube pública o en el borde). IBM Cloud Satellite® cumple con este requisito al permitir que aplicaciones modernas nativas de la nube se ejecuten en cualquier lugar que el cliente requiera, manteniendo al mismo tiempo un plano de control estándar y consistente para la administración de aplicaciones en toda la nube híbrida.

Además, muchas de estas aplicaciones de servicios financieros admiten cargas de trabajo reguladas, que requieren niveles estrictos de seguridad y cumplimiento, incluida la protección Zero Trust de las cargas de trabajo. IBM Cloud for Financial Services cumple ese requisito al proporcionar un marco de cumplimiento y seguridad de extremo a extremo que se puede utilizar para implementar y/o modernizar aplicaciones de forma segura en la nube híbrida.

En este documento, mostramos cómo implementar fácilmente una aplicación bancaria en ambos IBM Cloud para servicios financieros y Satélite, utilizando canalizaciones CI/CD/CC automatizadas de una manera común y consistente. Esto requiere un profundo nivel de seguridad y cumplimiento durante todo el proceso de construcción e implementación.

Introducción a conceptos y productos.

El objetivo de IBM Cloud for Financial Services es proporcionar seguridad y cumplimiento a las empresas de servicios financieros. Lo hace aprovechando estándares de la industria como NIST 800-53 y la experiencia de más de cien clientes de servicios financieros que forman parte del Financial Services Cloud Council. Proporciona un marco de control que se puede implementar fácilmente mediante el uso de arquitecturas de referencia, servicios de nube validados e ISV, así como los niveles más altos de cifrado y cumplimiento continuo (CC) en toda la nube híbrida.

IBM Cloud Satellite proporciona una verdadera experiencia de nube híbrida. Satellite permite ejecutar cargas de trabajo en cualquier lugar sin comprometer la seguridad. Un único panel de cristal brinda la facilidad de ver todos los recursos en un solo panel. Para implementar aplicaciones en estos entornos variables, hemos desarrollado un conjunto de sólidas cadenas de herramientas DevSecOps para crear aplicaciones, implementarlas en una ubicación satélite de manera segura y consistente y monitorear el entorno utilizando las mejores prácticas de DevOps.

En este proyecto, utilizamos una aplicación de generación de préstamos que se modernizó para utilizar Kubernetes y microservicios. Para brindar este servicio, la aplicación bancaria emplea un ecosistema de aplicaciones asociadas que interoperan utilizando el BIAN marco de referencia.

Descripción general de la aplicación

La aplicación utilizada en este proyecto es una aplicación de originación de préstamos desarrollada como parte del BIAN sin núcleo Iniciativa 2.0. Un cliente obtiene un préstamo personalizado a través de un canal en línea seguro ofrecido por un banco. La aplicación emplea un ecosistema de aplicaciones asociadas que interoperan en la arquitectura BIAN, que se implementa en IBM Cloud for Financial Services. BIAN Coreless Initiative permite a las instituciones financieras seleccionar los mejores socios para ayudar a llevar nuevos servicios al mercado de forma rápida y eficiente a través de arquitecturas BIAN. Cada componente o dominio de servicio BIAN se implementa a través de un microservicio, que se implementa en un clúster OCP en IBM Cloud.

Componentes de aplicación basados ​​en dominios de servicio BIAN

• Directorio de productos: Mantiene un directorio completo de los productos y servicios del banco.

• Créditos de consumo: Maneja el cumplimiento de un producto de préstamo de consumo. Esto incluye la configuración inicial del servicio de préstamo y la finalización de las tareas de procesamiento de productos programadas y ad hoc.

• Proceso de oferta del cliente/API: organiza el procesamiento de una oferta de producto para un cliente nuevo o establecido.

• Perfil de enrutamiento de grupo: Mantiene un pequeño perfil de indicadores clave para un cliente al que se hace referencia durante las interacciones con el cliente para facilitar las decisiones de ruta, servicio y cumplimiento de productos/servicios.

Descripción general del proceso de implementación

Se utilizó un flujo de trabajo ágil de DevSecOps para completar las implementaciones en la nube híbrida. Los flujos de trabajo de DevSecOps se centran en un proceso de entrega de software frecuente y confiable. La metodología es iterativa en lugar de lineal, lo que permite a los equipos de DevOps escribir código, integrarlo, ejecutar pruebas, entregar lanzamientos e implementar cambios de forma colaborativa y en tiempo real, manteniendo al mismo tiempo la seguridad y el cumplimiento bajo control.

La implementación de IBM Cloud for Financial Services se logró en un clúster de zona de aterrizaje segura y la implementación de la infraestructura también se automatiza utilizando políticas como código (terraformar). La aplicación se compone de varios componentes. Cada componente se implementó utilizando su propio Integración continua (CI), Entrega continua (CD) y Cumplimiento continuo (CC) canalización en un clúster RedHat OpenShift. Para lograr el despliegue en Satellite se reutilizaron los pipelines CI/CC y se creó un nuevo pipeline CD.

Integración continua

Cada componente de la implementación de IBM Cloud tenía su propio canal de CI. En la cadena de herramientas de CI se incluye un conjunto de procedimientos y enfoques recomendados. Se utiliza un escáner de código estático para inspeccionar el repositorio de la aplicación en busca de secretos almacenados en el código fuente de la aplicación, así como cualquier paquete vulnerable utilizado como dependencias dentro del código de la aplicación. Para cada confirmación de Git, se crea una imagen de contenedor y se asigna una etiqueta a la imagen según el número de compilación, la marca de tiempo y el ID de confirmación. Este sistema de etiquetado garantiza la trazabilidad de la imagen. Antes de crear la imagen, se prueba el Dockerfile. La imagen creada se guarda en un registro de imágenes privado. Los privilegios de acceso para la implementación del clúster de destino se configuran automáticamente mediante tokens API, que se pueden revocar. Se realiza un análisis de vulnerabilidades de seguridad en la imagen del contenedor. Se aplica una firma de Docker al finalizar con éxito. La adición de la etiqueta de imagen creada actualiza instantáneamente el registro de implementación. El uso de un espacio de nombres explícito dentro de un clúster sirve para aislar cada implementación. Cualquier código que se fusione en la rama especificada del repositorio de Git, expresamente para su implementación en el clúster de Kubernetes, se construye, verifica e implementa automáticamente.

Los detalles de cada imagen de Docker se almacenan en un repositorio de inventario, que se explica en detalle en la sección Implementación continua de este blog. Además, se recopilan pruebas a lo largo de cada recorrido del oleoducto. Esta evidencia describe qué tareas se llevaron a cabo en la cadena de herramientas, como escaneos de vulnerabilidades y pruebas unitarias. Esta evidencia se almacena en un repositorio git y en un depósito de almacenamiento de objetos en la nube, para que pueda ser auditada si es necesario.

Reutilizamos las cadenas de herramientas de CI actuales utilizadas para la implementación de IBM Cloud indicada anteriormente para la implementación de Satellite. Debido a que la aplicación permaneció sin cambios, no fue necesario reconstruir las canalizaciones de CI para la nueva implementación.

Entregas Continuas

El inventario sirve como fuente de verdad sobre qué artefactos se implementan en qué entorno/región; Esto se logra utilizando ramas de git para representar entornos, con un canal de promoción que actualiza los entornos en un enfoque basado en GitOps. En implementaciones anteriores, el inventario también alojaba archivos de implementación; estos son los archivos de recursos YAML Kubernetes que describen cada componente. Estos archivos de implementación se actualizarían con los descriptores de espacio de nombres correctos, junto con la versión más reciente de la imagen de Docker para cada componente.

Sin embargo, este enfoque nos resultó difícil por varias razones. Desde la perspectiva de las aplicaciones, tener que cambiar tantos valores de etiquetas de imágenes y espacios de nombres utilizando herramientas de reemplazo YAML (como YQ) fue crudo y complicado. Para Satellite en sí, utilizamos la estrategia de carga directa, y cada archivo YAML proporcionado cuenta como una "versión". Preferiríamos que una versión correspondiera a toda la aplicación, no solo a un componente o microservicio.

Se deseaba un enfoque diferente, por lo que rediseñamos el proceso de implementación para utilizar un gráfico Helm. Esto nos permitió parametrizar los valores importantes, como espacios de nombres y etiquetas de imágenes, e inyectarlos en el momento de la implementación. El uso de estas variables elimina gran parte de la dificultad asociada con el análisis de archivos YAML para un valor determinado. El gráfico de timón se creó por separado y se almacenó en el mismo registro de contenedor que las imágenes BIAN creadas. Actualmente estamos trabajando para desarrollar un canal de CI específico para validar cartas de timón; esto deshilachará el gráfico, lo empaquetará, lo firmará para verificar su veracidad (esto se verificará en el momento de la implementación) y almacenará el gráfico. Por ahora, estos pasos se realizan manualmente para desarrollar el gráfico. Hay un problema con el uso de gráficos de timón y configuraciones de Satellite juntos: la funcionalidad de timón requiere una conexión directa con un clúster de Kubernetes u OpenShift para funcionar de manera más efectiva y Satellite, por supuesto, no lo permitirá. Entonces, para resolver este problema, usamos la "plantilla de timón" para generar el gráfico con el formato correcto y luego pasamos el archivo YAML resultante a la función de carga de Satellite. Luego, esta función aprovecha la CLI de IBM Cloud Satellite para crear una versión de configuración que contiene la aplicación YAML. Aquí hay algunos inconvenientes: no podemos utilizar algunas funciones útiles que proporciona Helm, como la capacidad de rollback a una versión anterior del gráfico y las pruebas que se pueden realizar para garantizar que la aplicación esté funcionando correctamente. Sin embargo, podemos utilizar el mecanismo de reversión de Satellite como reemplazo y utilizar su versión como base para ello.

Cumplimiento continuo

La canalización CC es importante para el escaneo continuo de artefactos y repositorios implementados. El valor aquí está en encontrar vulnerabilidades recientemente reportadas que puedan haberse descubierto después de que se haya implementado la aplicación. Las últimas definiciones de vulnerabilidades de organizaciones como snyk y del Programa CVE se utilizan para realizar un seguimiento de estos nuevos problemas. La cadena de herramientas CC ejecuta un escáner de código estático a intervalos definidos por el usuario en los repositorios de aplicaciones que se proporcionan para detectar secretos en el código fuente de la aplicación y vulnerabilidades en las dependencias de la aplicación.

El canal también escanea imágenes de contenedores en busca de vulnerabilidades de seguridad. Cualquier incidente que se encuentre durante el escaneo o se actualice se marca con una fecha de vencimiento. La evidencia se crea y almacena en IBM Cloud Object Storage al final de cada ejecución que resume los detalles del análisis.

Información sobre DevOps Es valioso para realizar un seguimiento de los problemas y de la situación general de seguridad de su aplicación. Esta herramienta contiene todas las métricas de la cadena de herramientas anterior que se ejecuta en los tres sistemas: integración continua, implementación y cumplimiento. Cualquier resultado de escaneo o prueba se carga en ese sistema, y con el tiempo, puede observar cómo está evolucionando su postura de seguridad.

Incorporar CC en un entorno de nube es importante para industrias altamente reguladas, como las de servicios financieros, que desean proteger los datos de los clientes y las aplicaciones. En el pasado, este proceso era difícil y debía realizarse a mano, lo que pone en riesgo a las organizaciones. Pero con Centro de cumplimiento y seguridad de IBM Cloud, puede agregar verificaciones de cumplimiento automáticas y diarias a su ciclo de vida de desarrollo para ayudar a reducir este riesgo. Estas comprobaciones incluyen varias evaluaciones de las cadenas de herramientas de DevSecOps para garantizar la seguridad y el cumplimiento.

Basándonos en nuestra experiencia con este proyecto y otros proyectos similares, creamos un conjunto de mejores prácticas para ayudar a los equipos a implementar soluciones de nube híbrida para IBM Cloud for Financial Services e IBM Cloud Satellite:

• Integración continua
  • Mantenga una biblioteca de scripts común para aplicaciones similares en diferentes cadenas de herramientas. Este es el conjunto de instrucciones que determinan lo que debe hacer su cadena de herramientas de CI. Por ejemplo, el proceso de compilación de aplicaciones NodeJS generalmente seguirá la misma estructura, por lo que tiene sentido mantener una biblioteca de secuencias de comandos en un repositorio separado, al que se referirán las cadenas de herramientas al crear aplicaciones. Esto permite un enfoque coherente de la CI, promueve la reutilización y aumenta la mantenibilidad.
  • Alternativamente, las cadenas de herramientas de CI se pueden reutilizar para aplicaciones similares con el uso de activadores; Estos activadores separados se pueden usar para especificar qué aplicación se va a crear, dónde está el código de la aplicación y otras personalizaciones.

• Entregas Continuas
  • Para aplicaciones de múltiples componentes, mantenga un inventario único y, por lo tanto, una única cadena de herramientas de implementación para implementar todos los componentes enumerados en el inventario. Esto evita muchas repeticiones. Todos los archivos de implementación YAML de Kubernetes tienen el mismo mecanismo de implementación, por lo que una cadena de herramientas singular que se itera sobre cada uno de ellos es más lógico que mantener múltiples cadenas de herramientas de CD, las cuales esencialmente hacen lo mismo. La capacidad de mantenimiento ha aumentado y hay menos trabajo por hacer para implementar la aplicación. Si se desea, aún se pueden utilizar desencadenadores para implementar microservicios individuales.
  • Utilice gráficos Helm para aplicaciones complejas de múltiples componentes. El uso de Helm en el proyecto BIAN facilitó mucho la implementación. Los archivos de Kubernetes están escritos en YAML y el uso de analizadores de texto basados ​​en bash es engorroso si es necesario personalizar varios valores en el momento de la implementación. Helm simplifica esto mediante el uso de variables, lo que hace que la sustitución de valores sea mucho más efectiva. Además, Helm ofrece otras funciones, como control de versiones de toda la aplicación, control de versiones de gráficos, almacenamiento en el registro de la configuración de implementación y capacidades de reversión en caso de falla. Si bien la reversión no funcionará en implementaciones específicas de Satellite, esto se soluciona mediante el control de versiones de la configuración de Satellite.
• Cumplimiento continuo
  • Recomendamos encarecidamente configurar cadenas de herramientas CC como parte de su infraestructura para escanear continuamente códigos y artefactos en busca de vulnerabilidades recientemente expuestas. Normalmente, estos análisis se pueden ejecutar todas las noches o en cualquier horario que se adapte a su aplicación y situación de seguridad. Para realizar un seguimiento de los problemas y la postura de seguridad general de su aplicación, le sugerimos que utilice DevOps Insights.
  • También recomendamos el uso del Centro de seguridad y cumplimiento (SCC) para automatizar su postura de seguridad. El resumen de evidencia generado por las canalizaciones se puede cargar en el SCC, donde cada entrada en el resumen de evidencia se trata como un "hecho" relacionado con una tarea completada en una cadena de herramientas, ya sea un escaneo de vulnerabilidad, una prueba unitaria u otras cosas similares. . Luego, el SCC realizará pruebas de validación con la evidencia para determinar que se están siguiendo las mejores prácticas relacionadas con las cadenas de herramientas.
• Inventario
  • Como se mencionó anteriormente, con la implementación continua, es preferible mantener un único inventario de aplicaciones en el que se almacenarán todos los detalles de su microservicio, junto con (si no usa Helm) los archivos de implementación de Kubernetes. Esto permite disponer de una única fuente de información sobre el estado de sus implementaciones; Como las sucursales de su inventario representan entornos, mantener estos entornos en múltiples repositorios de inventario puede volverse engorroso muy rápidamente.
• Evidencia
  • El enfoque de los depósitos de evidencia debe tratarse de manera diferente al inventario. En este caso, es preferible un depósito de evidencia por componente; si los combinas, la evidencia almacenada puede volverse abrumadora y difícil de gestionar. Localizar piezas de evidencia específicas es mucho más eficiente si la evidencia se almacena en un repositorio específico para un componente. Para la implementación, es aceptable un único casillero de evidencia, ya que proviene de una única cadena de herramientas de implementación.
  • Recomendamos encarecidamente almacenar evidencia en un depósito de almacenamiento de objetos en la nube, así como utilizar la opción de repositorio git predeterminada. Esto se debe a que un depósito COS se puede configurar para que sea inmutable, lo que nos permite almacenar de forma segura la evidencia sin posibilidad de manipulación, lo cual es muy importante en el caso de pistas de auditoría.        

Conclusión

En este blog, mostramos nuestra experiencia implementando una aplicación bancaria basada en BIAN en la nube híbrida, es decir, utilizando canalizaciones DevSecOps para implementar la carga de trabajo tanto en IBM Cloud como en un entorno Satellite. Discutimos los pros y los contras de los diferentes enfoques y las mejores prácticas que derivamos después de realizar este proyecto. Esperamos que esto pueda ayudar a otros equipos a lograr su viaje a la nube híbrida con mayor coherencia y velocidad. Háganos saber sus pensamientos.

Explore lo que IBM tiene para ofrecer hoy