Actualmente, como parte de la implementación de la nueva estrategia de desarrollo y transformación digital, VTB está introduciendo activamente DevOps, integrando prácticas seguras de desarrollo de software en el proceso de ingeniería, aumentando el nivel de automatización y racionalizando los procesos de producción rutinarios. El propósito de estos cambios puede formularse en tres puntos clave: velocidad, confiabilidad y eficiencia. Naturalmente, al llevar a cabo tales transformaciones globales, se vuelve importante mantener reuniones informales abiertas, dentro de las cuales pueda compartir su propia experiencia, discutir las diversas encrucijadas y matices de la introducción de diversas prácticas de producción. Mitapas es un formato excelente para aumentar el compromiso general, la conciencia y el intercambio de experiencias tanto con colegas del banco como con socios de otras compañías.
Bajo el corte: lo más interesante de la primera reunión de VTB "DevSecOps: respuestas prácticas a preguntas no triviales", que se celebró en noviembre en el sitio de WeWork. A la reunión asistieron más de 200 especialistas.
Como empezó todo
Como saben, VTB es el segundo banco en Rusia en términos de número de clientes, activos e indicadores financieros. Desde 2018, el banco, como parte de la estrategia de desarrollo, comenzó a cambiar activamente su curso tecnológico y decidió una transición gradual hacia el desarrollo interno (interno) de los sistemas de TI. Antes de esto, la mayoría de los sistemas y soluciones fueron suministrados por proveedores. Ahora se ha vuelto importante mejorar la calidad, la seguridad y la velocidad de las entregas formando equipos internos y creando nuestro propio proceso de producción de TI. Todo parece ser simple y claro: hay casos, hay soluciones: tomar e implementar.
Pero en realidad, todo es mucho más complicado. En este camino, el banco tuvo que enfrentar muchas dificultades. Igor Shvakov, jefe del departamento de automatización de procesos de desarrollo de VTB, habló sobre esto en su informe.
El principal desafío es la singularidad de VTB en términos de TI. Históricamente, el banco se desarrolló a través de la adquisición e integración de grandes jugadores, cada uno de los cuales tenía su propia arquitectura de TI, hardware, procesos comerciales, etc. Desde 2018, VTB, VTB24 y el Banco de Moscú se han convertido en un VTB con su propia TI única. paisaje, infraestructura heterogénea, y en algún lugar aislada. Naturalmente, para llevar a cabo cambios transformacionales, construir simultáneamente un negocio (tal es una estrategia comercial) e implementar DevOps (y especialmente DevSecOps) en tales condiciones es una historia no trivial.
La primera dificultad que surgió al principio es un gran número de vendedores y, como consecuencia, una competencia propia limitada. Necesitábamos transferir contratistas externos que trabajaban fuera del perímetro a la infraestructura y los procesos del banco. La segunda dificultad es que los clientes empresariales exigieron el desarrollo activo de los sistemas de TI para garantizar el logro de un alto rendimiento empresarial. Por lo tanto, tuvimos que trabajar en una situación de creciente actividad transaccional de los clientes y una alta dependencia de integración de los sistemas.
Inicialmente, planeamos hacer la transición a los rieles internos gradualmente: seleccione sistemas y defina objetivos, luego prepare equipos e infraestructura, y en la última etapa seleccione herramientas y configure DevSecOps Pipeline. Pero en realidad, teníamos que hacer todo de una vez, y al mismo tiempo resolver los problemas que surgen.
Experiencia de replicación del sistema
Como no teníamos la infraestructura para el desarrollo interno, se decidió virtualizar todo y cambiar a la arquitectura x86 para minimizar los costos y gastos. Como resultado, se construyó una plataforma de infraestructura sobre la base de la solución hiperconvergente Nutanix ya existente, y le transferimos todas las herramientas de desarrollo en la mayor medida posible.
Pero el hierro es hierro, y la gente trabaja en él. En este sentido, surgió la pregunta de cómo formar equipos. Decidimos centrarnos en las siguientes relaciones: dos desarrolladores internos deberían tener un tecnólogo, un equipo de 10 desarrolladores debería tener un ingeniero DevOps y dos probadores de automatización. Esto es lo que hemos llegado a nuestra propia experiencia, trabajando con más de dos docenas de sistemas. Y este enfoque ha sido muy efectivo.
La siguiente pregunta interesante es cómo transferir sistemas al circuito bancario.
Como regla general, el ciclo de traducción estándar de un sistema lleva de 7 a 8 meses. Se presenta de la siguiente manera.
- Durante los primeros dos meses hay una selección de personal. Al mismo tiempo, se analizan las relaciones contractuales con contratistas externos para determinar la posibilidad de transferirlos a trabajar en el circuito bancario.
- Para el tercer mes, se está formando la competencia central en el sistema y se está completando el equipo de DevOps en términos de desarrollo, configuración de tuberías y pruebas automatizadas. Al mismo tiempo, el acceso a los sistemas de información para equipos externos está regulado y provisto.
- El cuarto mes: capacitación del equipo y transferencia del código al repositorio bancario del proveedor.
- Quinto: desarrollo conjunto por parte de los equipos del banco y un contratista externo, afinando Pipeline y el lanzamiento de las primeras entregas.
- En el sexto y séptimo mes, las revisiones piloto pasan por todo el proceso ya directamente en la infraestructura del banco.
- Resultado: por séptimo mes, el equipo conjunto ya está trabajando dentro del mismo ciclo de desarrollo en el banco.
La experiencia muestra que con este enfoque es posible organizar equipos bien coordinados e implementar una gran cantidad de proyectos en un año y medio. En palabras, todo es sencillo, pero en el proceso de transición tuvimos problemas. Uno de ellos es un gran volumen de equipos de un proveedor externo. Por ejemplo, el equipo de uno de los proveedores estaba formado por más de 200 desarrolladores. Ahora la mayoría de ellos trabajan dentro de un circuito común en la infraestructura bancaria. Y había muchos matices similares.
En este momento, el banco ya cuenta con más de veinte equipos de desarrollo (más de 500 desarrolladores externos y de tiempo completo), cada uno de los cuales utiliza su propia cartera en términos de CI. Para la mayoría de estos comandos, se implementa el paso de CD. También hay varios sistemas que ya utilizan la entrega automática de cambios a los circuitos industriales.
Los enfoques implementados hicieron posible construir una tubería y transferir el desarrollo al segmento interno, no solo para nuevos sistemas con una arquitectura de microservicio flexible, sino también para una gran cantidad de sistemas monolíticos complejos basados en soluciones "en caja" adaptadas a los requisitos del banco.
Desde el principio, no buscamos formas fáciles y demostramos que con las competencias adecuadas de los empleados, puede implementar prácticas DevOps para cualquier sistema de cualquier complejidad.
Ahora el proceso está ganando impulso, se están agregando nuevos sistemas, la pila tecnológica se está estandarizando, etapas individuales de la tubería, informes, reglas de trabajo. Además, el enfoque para replicar prácticas a otros equipos y bloques del banco se está moviendo a un nuevo nivel de madurez, se están optimizando los procesos, se especifican las funciones y competencias necesarias dentro de los equipos, y se especifica la responsabilidad de los participantes. En general, el proceso de replicación se ha puesto en marcha y se está transformando desde el inicio dentro de un gran banco a una solución empresarial de alta tecnología. Este camino se cubrió en poco más de un año y medio desde el momento de instalar el hierro en el centro de datos para implementar los cambios en modo automático en el circuito industrial o preindustrial.
Trampas
Como parte de la nueva estrategia de VTB, la transición a las prácticas DevSecOps se ha señalado como una de las corrientes estratégicas a nivel bancario. Alexander Kalabukhov, jefe del Centro de Prácticas de Ingeniería del Departamento para el Desarrollo de Sistemas de Producción de TI y Mantenimiento VTB, habló sobre esto en su informe.
Se decidió transformar los servicios involucrados en el desarrollo, prueba y operación en equipos multifuncionales que trabajan en la misma funcionalidad comercial. Los equipos incluyen especialistas en arquitectura y desarrollo, tecnólogos, evaluadores e ingenieros de DevOps. En los servicios centralizados, solo queda eso que tiene competencias únicas o vive en un ritmo único (24/7): administración aplicada y del sistema, seguridad de la información.
Dicha transición a equipos interfuncionales plantea nuevos requisitos para los procesos de gestión de código (fuente, prueba, implementación, etc.), gestión de pruebas y desarrollo. Donde las brechas de proceso eran previamente aceptables, ahora se están convirtiendo en obstáculos críticos, y estamos mejorando nuestro panorama de DevSecOps en términos de herramientas y unir las brechas de proceso.
Hablando de herramientas. Un problema es que los bancos caen bajo ciertos requisitos regulatorios relacionados con el secreto bancario y otras restricciones similares. Cualquier sistema en el banco pasa la etapa de pruebas de aceptación para cumplir con los requisitos de seguridad de la información, incluso en términos de herramientas DevOps. Desafortunadamente, la mayoría de los ingenieros de DevOps nunca han trabajado en un entorno regulado tan difícil, y a menudo saben poco sobre la auditoría de estas herramientas, sobre cómo se debe limitar el acceso a la red y el acceso a los datos, qué hacer con los secretos intercambiados entre las herramientas de DevOps etc.
La tarea principal de crear protección de datos dentro del banco es garantizar que ninguna persona tenga acceso a todos los datos a la vez. Es por eso que los desarrolladores no pueden realizar las funciones de los administradores de aplicaciones y sistemas. Existen limitaciones similares para los ingenieros de DevSec. Naturalmente, ninguno de estos especialistas puede ser un administrador de seguridad de la información. Una vez que se definen todos los roles y el perímetro de su autoridad, puede incorporar el proceso estándar para otorgar derechos de herramienta DevOps al proceso general de otorgar derechos en un banco.
Un aspecto importante es la seguridad de la red. Debe cumplir con la regla de que una conexión solo se puede hacer desde circuitos más confiables a otros menos confiables. Si el proceso se lleva a cabo en la dirección opuesta, es necesario proporcionar brechas de red utilizando medios especiales. Las conexiones de red deben establecerse de forma segura y aún encriptarse entre ellas. De lo contrario, los virus y otro software malicioso pueden entrar en la cadena, lo que puede provocar fugas de datos e incidentes en entornos industriales.
Los problemas de seguridad están influenciados por la forma en que se organizan los datos, ya que hay varios entornos de desarrollo y prueba, es necesario unirse al circuito del banco a través de VPN para que los contratistas puedan trabajar desde sus computadoras portátiles. Además, hay circuitos especiales donde se permite el acceso a un círculo limitado de personas, los datos no deben ir más allá de estos circuitos.
Por lo tanto, a pesar de toda la riqueza de las herramientas DevOps existentes, es necesario estandarizarlas. Con el enfoque correcto, la seguridad de la información en el banco introduce restricciones al proceso de desarrollo y operación, pero no impide la introducción de nuevas tecnologías.
Ciberseguridad sobre todo
En el contexto de la transformación empresarial y un tiempo más corto para el lanzamiento de nuevos productos digitales en el mercado, el principal desafío industrial es garantizar la seguridad de la información en todas las etapas del proceso de producción continuo. El tema de la integración de las prácticas de desarrollo de software seguro en DevOps fue el tema de un informe de Yuri Sergeyev, socio gerente de Swordfish Security y líder de la industria DevSecOps en Rusia.
La implementación del paradigma de ciberseguridad en DevOps es un proceso bastante complicado, dentro del cual la capa de prácticas de Seguridad envuelve todo el ciclo de ingeniería de producción. Las prácticas de seguridad de la información están respaldadas por una pila instrumental integrada en todas las etapas del proceso.
Las prácticas de IS necesarias incluyen:
- Control de componentes de código abierto cuando caen en el perímetro de desarrollo (Análisis de código abierto, OSA);
- Análisis de código estático (pruebas de seguridad de aplicaciones estáticas, SAST);
- Monitoreo de la composición de componentes de software (Software Composition Analysis, SCA);
- Todos los tipos de análisis dinámico (Pruebas de seguridad de aplicaciones dinámicas, DAST / Pruebas de seguridad de aplicaciones interactivas, IAST / Pruebas de seguridad de aplicaciones conductuales, BAST);
- Análisis de código binario y control de composición de contenedores (Bytecode and Container Analysis, BCA);
- Implementación de WAF (Firewall de aplicaciones web).
Al mismo tiempo, los aspectos más importantes al escalar y transformar los procesos DevOps en el paradigma DevSecOps derivado son:
- Uso de bibliotecas, marcos y componentes de software seguros de forma predeterminada durante el proceso de desarrollo (Secure-by-Default);
- Integración de las prácticas de tecnología IS al comienzo de la canalización de CI / CD (enfoque Shift-Left);
- Automatización de todos los procesos en el concepto de todo como un código;
- Formación de una comunidad de defensores de la seguridad que son responsables de las tareas de seguridad de la información en los equipos de producción y son las guías de una cultura de seguridad de ingeniería;
- Aplicación del modelo de madurez DevSecOps tanto para evaluar el proceso existente como para la mejora continua;
- Garantizar la transparencia de todas las actividades de seguridad para todos los participantes en el proceso de producción de ingeniería.
Por separado, vale la pena enfatizar la importancia de la práctica de DevSecOps-orchestration (Application Security Testing Orchestration, ASTO), que proporciona integración de extremo a extremo de la pila de herramientas IS con herramientas de desarrollo, gestión automatizada de la tubería de seguridad (tuberías), así como la recopilación, consolidación y análisis de todos los datos de forma continua Proceso de desarrollo de software seguro. La práctica de la orquestación puede ahorrar recursos significativamente y reducir en más de 10 veces el tiempo total de implementación de la iniciativa DevSecOps en entornos de ingeniería complejos y heterogéneos.
Si hablamos de la transformación en su conjunto, podemos distinguir los siguientes factores clave de éxito:
- La introducción de una herramienta o elemento separado del proceso de seguridad cibernética es, por supuesto, un paso importante, pero en ningún caso es una bala de plata para abordar los problemas de seguridad del software desarrollado a escala industrial. La clave del éxito es solo la aplicación integrada de todo el conjunto de prácticas de seguridad de la información.
- La aplicación de la práctica de la orquestación protegerá a los equipos de ingeniería y al equipo de seguridad de la información del caos tecnológico de la integración de instrumentos a la altura de las rodillas y la automatización incontrolada de "patchwork".
- La recopilación de datos y la posterior visualización de métricas le permitirán administrar el proceso de extremo a extremo, lograr una total transparencia y también crear la base necesaria para la aplicación de prácticas de aprendizaje automático en el futuro.