El banco subcontrata sus proyectos a muchos contratistas. Los "externos" escriben código y luego transmiten los resultados en una forma no muy conveniente. Específicamente, el proceso fue el siguiente: entregaron un proyecto que pasó pruebas funcionales con ellos y luego fue probado dentro del perímetro bancario para integración, carga, etc. A menudo se descubría que las pruebas fallaban. Luego todo volvió al desarrollador externo. Como puedes adivinar, esto significó largos plazos para corregir errores.
El banco decidió que era posible y necesario arrastrar todo el oleoducto bajo su protección, desde los compromisos hasta la liberación. Para que todo esté uniforme y bajo el control de los equipos responsables del producto en el banco. Es decir, como si el contratista externo simplemente estuviera trabajando en algún lugar de la habitación contigua de la oficina. En la pila corporativa. Este es un Devops ordinario.
¿De dónde vino Sec? La seguridad del banco ha planteado grandes exigencias sobre cómo puede trabajar un contratista externo en el segmento de red, qué acceso tiene alguien, cómo y quién trabaja con el código. Lo que pasa es que IB todavía no sabía que cuando los contratistas trabajan al aire libre, se siguen pocas normas bancarias. Y luego, en un par de días, todo el mundo tendrá que empezar a observarlos.
La simple revelación de que el contratista tenía acceso total al código del producto ya había puesto su mundo patas arriba.
En este momento comenzó la historia de DevSecOps, de la que quiero hablarles.
¿Qué conclusiones prácticas sacó el banco de esta situación?
Hubo mucha controversia sobre el hecho de que todo se está haciendo de forma incorrecta. Los desarrolladores dijeron que la seguridad sólo está ocupada tratando de interferir con el desarrollo y ellos, como vigilantes, intentan prohibir sin pensar. A su vez, los especialistas en seguridad dudaron entre elegir entre los puntos de vista: “los desarrolladores crean vulnerabilidades en nuestro circuito” y “los desarrolladores no crean vulnerabilidades, sino que son ellos mismos”. La disputa habría continuado durante mucho tiempo si no fuera por las nuevas demandas del mercado y la aparición del paradigma DevSecOps. Se pudo explicar que esta misma automatización de los procesos, teniendo en cuenta los requisitos de seguridad de la información "listas para usar", ayudará a todos a estar contentos. En el sentido de que las reglas se escriben inmediatamente y no cambian durante el juego (la seguridad de la información no prohibirá algo inesperado), y los desarrolladores mantienen a la seguridad de la información informada sobre todo lo que sucede (la seguridad de la información no se topa con algo repentinamente) . Cada equipo también es responsable de la máxima seguridad, y no algunos hermanos mayores abstractos.
- Dado que los empleados externos ya tienen acceso al código y a una serie de sistemas internos, probablemente sea posible eliminar de los documentos el requisito "el desarrollo debe realizarse íntegramente en la infraestructura del banco".
- Por otro lado, necesitamos fortalecer el control sobre lo que está sucediendo.
- El compromiso fue la creación de equipos multifuncionales, en los que los empleados trabajen en estrecha colaboración con personas externas. En este caso, debes asegurarte de que el equipo trabaje con herramientas en los servidores del banco. Desde el principio hasta el final.
Es decir, se puede permitir la entrada a los contratistas, pero es necesario asignarles segmentos separados. Para que no traigan algún tipo de infección desde el exterior a la infraestructura del banco y para que no vean más de lo necesario. Bueno, para que sus acciones queden registradas. DLP para protección contra fugas, todo esto estaba incluido.
En principio, todos los bancos llegan a esto tarde o temprano. Aquí seguimos el camino trillado y acordamos los requisitos para entornos en los que trabajan "externos". Apareció una gama máxima de herramientas de control de acceso, herramientas de verificación de vulnerabilidades, análisis antivirus en circuitos, ensamblajes y pruebas. Esto se llama DevSecOps.
De repente quedó claro que si antes de DevSecOps la seguridad bancaria no tenía control sobre lo que sucede en el lado del desarrollador, entonces en el nuevo paradigma la seguridad se controla de la misma manera que los eventos ordinarios en la infraestructura. Solo que ahora hay alertas sobre montajes, control de bibliotecas, etc.
Sólo queda trasladar los equipos al nuevo modelo. Bueno, crea la infraestructura. Pero esto son nimiedades, es como dibujar un búho. En realidad ayudamos con la infraestructura y en ese momento los procesos de desarrollo estaban cambiando.
Que ha cambiado
Decidimos implementarlo en pequeños pasos, porque entendimos que muchos procesos fracasarían y muchos “externos” tal vez no podrían soportar las nuevas condiciones de trabajo bajo la supervisión de todos.
Primero, creamos equipos multifuncionales y aprendimos a organizar proyectos teniendo en cuenta los nuevos requisitos. En el sentido organizacional discutimos qué procesos. El resultado fue un esquema del proceso de montaje con todos los responsables.
- CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Prueba: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Presentación (informes, comunicación): Grafana, Kibana, Jira, Confluence, RocketChat.
- Operaciones (mantenimiento, gestión): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Pila seleccionada:
- Base de conocimientos: Confluencia de Atlassian;
- Rastreador de tareas - Atlassian Jira;
- Repositorio de artefactos - "Nexus";
- Sistema de integración continua - "Gitlab CI";
- Sistema de análisis continuo - “SonarQube”;
- Sistema de análisis de seguridad de aplicaciones: “Micro Focus Fortify”;
- Sistema de comunicación - "GitLab Mattermost";
- Sistema de gestión de configuración - "Ansible";
- Sistema de seguimiento: “ELK”, “TICK Stack” (“InfluxData”).
Comenzaron a crear un equipo que estaría listo para arrastrar a los contratistas al interior. Se comprende que hay varias cosas importantes:
- Todo debería estar unificado, al menos a la hora de transmitir código. Porque había tantos contratistas como procesos de desarrollo diferentes y con particularidades propias. Era necesario acomodar a todos aproximadamente en uno, pero con opciones.
- Hay muchos contratistas y la creación manual de infraestructura no es adecuada. Cualquier tarea nueva debe comenzar muy rápidamente; es decir, la instancia debe implementarse casi instantáneamente para que los desarrolladores tengan un conjunto de soluciones para administrar su canalización.
Para dar el primer paso era necesario entender lo que se estaba haciendo. Y teníamos que determinar cómo llegar allí. Comenzamos ayudando a dibujar la arquitectura de la solución de destino tanto en infraestructura como en automatización de CI/CD. Luego comenzamos a ensamblar este transportador. Necesitábamos una infraestructura, igual para todos, por donde circularan los mismos transportadores. Ofrecimos opciones con cálculos, pensó el banco, luego decidimos qué se construiría y con qué fondos.
Lo siguiente es la creación del circuito: instalación del software, configuración. Desarrollo de scripts para el despliegue y gestión de infraestructura. Luego viene la transición al soporte del transportador.
Decidimos probar todo en el piloto. Curiosamente, durante la prueba piloto, apareció por primera vez cierta pila en el banco. Entre otras cosas, se ofreció a un proveedor nacional de una de las soluciones el alcance del piloto para un lanzamiento rápido. Seguridad lo conoció mientras pilotaba y dejó una impresión inolvidable. Cuando decidimos cambiar, afortunadamente, la capa de infraestructura fue reemplazada por una solución Nutanix, que ya estaba en el banco antes. Además, antes era para VDI, pero lo reutilizamos para servicios de infraestructura. En volúmenes pequeños no encajaba en la economía, pero en volúmenes grandes se convertía en un entorno excelente para el desarrollo y las pruebas.
El resto de la pila es más o menos familiar para todos. Se utilizaron herramientas de automatización en Ansible y los especialistas en seguridad trabajaron en estrecha colaboración con ellas. El banco utilizaba la pila Atlassin antes del proyecto. Herramientas de seguridad de Fortinet: fue propuesto por el propio personal de seguridad. El marco de prueba fue creado por el banco, sin hacer preguntas. El sistema de repositorio generó dudas; tuve que acostumbrarme.
A los contratistas se les entregó una nueva pila. Nos dieron tiempo para reescribirlo para GitlabCI, migrar Jira al segmento bancario, etc.
paso a paso
Paso 1. Primero, utilizamos una solución de un proveedor nacional, el producto se conectó a un nuevo segmento de red DSO creado. La plataforma fue elegida por su tiempo de entrega, flexibilidad de escalado y la posibilidad de automatización total. Pruebas realizadas:
- Posibilidad de gestión flexible y totalmente automatizada de la infraestructura de la plataforma de virtualización (red, subsistema de disco, subsistema de recursos informáticos).
- Automatización de la gestión del ciclo de vida de las máquinas virtuales (plantillas, instantáneas, copias de seguridad).
Después de la instalación y configuración básica de la plataforma, se utilizó como punto de ubicación de los subsistemas de la segunda etapa (herramientas DSO, esquemas de desarrollo de sistemas minoristas). Se crearon los conjuntos de canalizaciones necesarios: creación, eliminación, modificación y copia de seguridad de máquinas virtuales. Estos oleoductos se utilizaron como la primera etapa del proceso de implementación.
El resultado es que el equipo proporcionado no cumple con los requisitos de rendimiento y tolerancia a fallas del banco. El DIT del banco decidió crear un complejo basado en el paquete de software Nutanix.
etapa 2. Tomamos la pila que se definió y escribimos scripts de instalación y posconfiguración automatizados para todos los subsistemas para que todo se transfiriera del circuito piloto al circuito de destino lo más rápido posible. Todos los sistemas se implementaron en una configuración tolerante a fallas (donde esta posibilidad no está limitada por las políticas de licencia del proveedor) y se conectaron a subsistemas de recopilación de eventos y métricas. IB analizó el cumplimiento de sus requisitos y dio luz verde.
etapa 3. Migración de todos los subsistemas y sus configuraciones al nuevo PAC. Se reescribieron los scripts de automatización de la infraestructura y se completó la migración de los subsistemas DSO en un modo totalmente automatizado. Los contornos del desarrollo de la propiedad intelectual fueron recreados por los canales de los equipos de desarrollo.
Paso 4. Automatización de la instalación de software de aplicaciones. Estas tareas fueron establecidas por los jefes de equipo de los nuevos equipos.
Paso 5. Explotación.
Acceso remoto
Los equipos de desarrollo pidieron la máxima flexibilidad a la hora de trabajar con el circuito, y desde el principio del proyecto se planteó la necesidad de acceso remoto desde ordenadores portátiles. El banco ya tenía acceso remoto, pero no era apto para desarrolladores. El hecho es que el esquema utilizaba la conexión del usuario a una VDI protegida. Esto era adecuado para aquellos que en su lugar de trabajo sólo necesitaban correo y un paquete de oficina. Los desarrolladores necesitarían clientes pesados, de alto rendimiento y con muchos recursos. Y por supuesto, tenían que ser estáticos, ya que la pérdida de la sesión de usuario para quienes trabajan con VStudio (por ejemplo) u otro SDK es inaceptable. La organización de una gran cantidad de VDI estáticas de gran volumen para todos los equipos de desarrollo aumentó considerablemente el costo de la solución VDI existente.
Decidimos trabajar en el acceso remoto directamente a los recursos del segmento de desarrollo. Jira, Wiki, Gitlab, Nexus, bancos de construcción y pruebas, infraestructura virtual. Los guardias de seguridad han exigido que el acceso sólo se pueda proporcionar sujeto a lo siguiente:
- Utilizando tecnologías ya disponibles en el banco.
- La infraestructura no debe utilizar controladores de dominio existentes que almacenen registros de objetos de cuentas productivas.
- El acceso debe limitarse únicamente a aquellos recursos requeridos por un equipo específico (de modo que un equipo de producto no pueda acceder a los recursos de otro equipo).
- Máximo control sobre RBAC en los sistemas.
Como resultado, se creó un dominio separado para este segmento. Este dominio albergaba todos los recursos del segmento de desarrollo, tanto las credenciales de usuario como la infraestructura. El ciclo de vida de los registros en este dominio se gestiona utilizando el IdM existente en el banco.
El acceso remoto directo se organizó sobre la base del equipamiento existente del banco. El control de acceso se dividió en grupos AD, a los que correspondían reglas sobre contextos (un grupo de productos = un grupo de reglas).
Gestión de plantillas de VM
La velocidad de creación de un bucle de ensamblaje y prueba es uno de los principales KPI establecidos por el jefe de la unidad de desarrollo, porque la velocidad de preparación del entorno afecta directamente el tiempo general de ejecución del pipeline. Se consideraron dos opciones para preparar imágenes base de VM. El primero son los tamaños mínimos de imagen, predeterminados para todos los productos del sistema, el máximo cumplimiento de las políticas del banco en materia de configuración. La segunda es la imagen base, que contiene un POPPO de alta resistencia instalado, cuyo tiempo de instalación podría influir en gran medida en la velocidad de ejecución de la tubería.
Durante el desarrollo también se tuvieron en cuenta los requisitos de infraestructura y seguridad: mantener las imágenes actualizadas (parches, etc.), integración con SIEM y configuraciones de seguridad según los estándares bancarios.
Como resultado, se decidió utilizar imágenes mínimas para minimizar el costo de mantenerlas actualizadas. Es mucho más fácil actualizar el sistema operativo base que parchear cada imagen para nuevas versiones de POPPO.
Con base en los resultados, se formó una lista del conjunto mínimo requerido de sistemas operativos, cuya actualización es realizada por el equipo de operación, y los scripts de la tubería son enteramente responsables de actualizar el software y, si es necesario, cambiar la versión. del software instalado: simplemente transfiera la etiqueta requerida a la tubería. Sí, esto requiere que el equipo de producto devops tenga escenarios de implementación más complejos, pero reduce en gran medida el tiempo operativo requerido para admitir imágenes base, cuyo mantenimiento podría requerir más de cien imágenes de VM base.
Acceso a Internet
Otro obstáculo para la seguridad bancaria fue el acceso a los recursos de Internet desde el entorno de desarrollo. Además, este acceso se puede dividir en dos categorías:
- Acceso a infraestructura.
- Acceso de desarrollador.
El acceso a la infraestructura se organizó mediante proxy de repositorios externos con Nexus. Es decir, no se proporcionó acceso directo desde máquinas virtuales. Esto permitió llegar a un compromiso con la seguridad de la información, que se oponía categóricamente a cualquier acceso al mundo exterior desde el segmento de desarrollo.
Los desarrolladores necesitaban acceso a Internet por razones obvias (stackoverflow). Y aunque todos los comandos, como se mencionó anteriormente, tenían acceso remoto al circuito, no siempre es conveniente cuando no se puede presionar Ctrl+v desde el lugar de trabajo del desarrollador en el banco en el IDE.
Se llegó a un acuerdo con el EI según el cual inicialmente, en la etapa de prueba, el acceso se proporcionará a través de un proxy bancario basado en una lista blanca. Una vez finalizado el proyecto, el acceso se transferirá a la lista negra. Se prepararon enormes tablas de acceso, que indicaban los principales recursos y repositorios a los que se requería acceso al inicio del proyecto. Coordinar estos accesos llevó bastante tiempo, lo que permitió insistir en una transición lo más rápida posible a las listas negras.
resultados
El proyecto finalizó hace poco menos de un año. Curiosamente, todos los contratistas cambiaron a la nueva pila a tiempo y nadie se fue debido a la nueva automatización. IB no tiene prisa por compartir comentarios positivos, pero tampoco se queja, de lo que podemos concluir que les gusta. Los conflictos han disminuido porque la seguridad de la información vuelve a sentirse en control, pero no interfiere con los procesos de desarrollo. Los equipos recibieron más responsabilidades y la actitud general hacia la seguridad de la información mejoró. El banco entendió que la transición a DevSecOps era casi inevitable y, en mi opinión, lo hizo de la manera más cuidadosa y correcta.
Alexander Shubin, arquitecto de sistemas.
Fuente: habr.com