🛶 😺 🕷️ DevOps vs DevSecOps: cómo se veía en un banco 😯 ⛺️ 👩🏿‍🤝‍👩🏽

El banco externaliza sus proyectos a muchos contratistas. Los "externos" escriben el código, luego transmiten los resultados en una forma no muy conveniente. Específicamente, el proceso se veía así: transfirieron un proyecto que les pasó pruebas funcionales, y luego ya se probó dentro del perímetro bancario para integración, carga, etc. A menudo se descubrió que las pruebas eran feyl. Luego todo volvió al desarrollador externo. Como puede adivinar, esto significó mucho tiempo para corregir errores.

El banco decidió que es posible y necesario arrastrar todo el oleoducto hacia sí mismo "bajo el ala" desde los compromisos hasta la liberación. Para que todo sea consistente y esté bajo el control de los equipos responsables del producto en el banco. Es decir, como si el contratista externo simplemente trabajara en algún lugar de la habitación contigua de la oficina. En la pila corporativa. Esta es una devopa ordinaria.

¿De dónde vino Sec? La seguridad bancaria ha establecido altas demandas sobre cómo un contratista externo puede trabajar en el segmento de red, quién tiene acceso, cómo y quién trabaja con el código. Es solo que IB aún no sabía que cuando los contratistas trabajan fuera, se respetan pocos estándares bancarios. Y aquí, en un par de días, todos deben comenzar a observarlos.

Una simple revelación de que el contratista tiene acceso completo al código del producto ya ha trastornado su mundo.

En ese momento, comenzó la historia de DevSecOps, sobre la cual quiero contar.

¿Qué banco sacó conclusiones prácticas de esta situación?

Hubo mucha controversia sobre el hecho de que todo se está haciendo mal en la esfera. Los desarrolladores dijeron que la seguridad solo está ocupada con intentos de obstaculizar el desarrollo, y ellos, como vigilantes, intentan prohibir sin pensar. A su vez, los guardias de seguridad dudaron entre elegir entre puntos de vista: "los desarrolladores crean vulnerabilidades en nuestro circuito" y "los desarrolladores no crean vulnerabilidades, pero ellos mismos lo son". El debate continuaría durante mucho tiempo, de no ser por los nuevos requisitos del mercado y el surgimiento del paradigma DevSecOps. Fue posible explicar que esta misma automatización de procesos teniendo en cuenta los requisitos de seguridad de la información "listos para usar" ayudará a todos a estar satisfechos. En el sentido de que las reglas se escriben de inmediato y no cambian durante el juego (IS no prohibirá algo inesperadamente), y los desarrolladores mantienen informado a IS sobre todo lo que sucede (IS no encuentra algo repentinamente).Cada equipo es responsable de la máxima seguridad, y no de algunos hermanos mayores abstractos.

, , « ».
, , .
- , . , . .

Es decir, los contratistas pueden ser permitidos, pero debe hacerlos segmentos separados. Para que no arrastren fuera de algún tipo de infección a la infraestructura del banco y no vean más de lo necesario. Bueno, para que se registren sus acciones. DLP para protección contra "sumideros", todo esto se aplicó.

En principio, todos los bancos llegan a esto tarde o temprano. Luego nos salimos de los caminos trillados y acordamos los requisitos para tales entornos donde trabajan "extraños". Apareció un conjunto máximo de herramientas de control de acceso, verificadores de vulnerabilidad, análisis antivirus en circuitos, ensamblajes y pruebas. Esto es lo que llamaron DevSecOps.

De repente se hizo evidente que si antes de esta seguridad bancaria DevSecOps no tenía control sobre lo que estaba sucediendo del 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 en ensamblajes, control de bibliotecas, etc.

Solo queda transferir el equipo a un nuevo modelo. Bueno, crea una infraestructura. Pero estos son pequeños, así es como dibujar un búho. En realidad, ayudamos con la infraestructura, y en este momento los procesos de desarrollo cambiaron.

Lo que estaba cambiando

Decidieron implementarlo en pequeños pasos, porque se dieron cuenta de que muchos procesos se desmoronarían y que muchos "extraños" podrían no ser capaces de soportar las nuevas condiciones de trabajo bajo la supervisión de todos.

Primero, creamos equipos multifuncionales y aprendimos cómo organizar proyectos teniendo en cuenta los nuevos requisitos. En términos de discusión organizacional, qué procesos. Resultó la tubería 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, Atascama.
Presentación (informes, comunicación): Grafana, Kibana, Jira, Confluence, RocketChat.
Operaciones : Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Seleccionó una pila:

Base de conocimiento - Confluencia atlassiana;
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 la configuración - "Ansible";
Sistema de monitoreo - "ELK", "TICK Stack" ("InfluxData").

Comenzaron a crear un equipo que estaría listo para atraer a los contratistas. Se ha dado cuenta de que hay varias cosas importantes:

. — . , .
, . — , .

Para dar el primer paso, tenía que entender lo que se estaba haciendo. Y tuvimos que determinar cómo proceder con esto. Comenzamos ayudando a dibujar la arquitectura de la solución objetivo, tanto en infraestructura como en automatización de CI / CD. Entonces comenzamos a armar este transportador. Necesitábamos una infraestructura, la misma para todos, donde corrieran los mismos transportadores. Ofrecimos opciones con acuerdos, pensó el banco, luego tomamos una decisión sobre qué y sobre qué significa que se construirá.

Creación posterior del circuito: instalación del software, configuración. Desarrollo de scripts para infraestructura y gestión de despliegue. Lo siguiente es la transición al soporte de la tubería.

Decidimos ejecutar todo en el piloto. Curiosamente, durante el pilotaje, una cierta pila apareció en el banco por primera vez. Entre otras cosas, se propuso un proveedor nacional de una de las soluciones para un lanzamiento temprano para el volumen del piloto. Safety lo conoció durante el pilotaje, y esto dejó una experiencia inolvidable. Cuando decidieron cambiar, afortunadamente, la capa de infraestructura fue reemplazada por una solución nutanix que ya estaba en el banco antes. Y antes de eso era para VDI, y lo reutilizamos para servicios de infraestructura. En pequeños volúmenes, no encajaba en la economía, pero en grandes volúmenes se convirtió en un excelente entorno 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 la parte Ansible, y los guardias de seguridad trabajaron estrechamente con ellos. La pila Atlassinovsky fue utilizada por el banco antes del proyecto. Fortinet Security Tools: fue propuesto por los propios guardias de seguridad. El marco de prueba fue creado por el banco, sin preguntas. Las preguntas fueron causadas por el sistema de repositorio, tuve que acostumbrarme.

Los contratistas recibieron una nueva pila. Dieron tiempo para reescribir bajo GitlabCI, y para migrar a Jira al segmento bancario, etc.

Paso a paso

Etapa 1. Primero, utilizamos la solución de un proveedor nacional, el producto se cambió al segmento de red DSO recién creado. La plataforma fue seleccionada por tiempos de entrega, escalabilidad y capacidades 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 la configuración básica de la plataforma, se utilizó como punto de colocación de los subsistemas de la segunda etapa (herramientas DSO, esquemas de desarrollo de sistemas minoristas). Se crearon los conjuntos de tuberías necesarios: crear, eliminar, modificar y realizar copias de seguridad de máquinas virtuales. Estas tuberías se utilizaron como la primera etapa del proceso de implementación.

Resultado: el equipo proporcionado no cumple con los requisitos del banco para el rendimiento y la tolerancia a fallas. DIT Bank decidió crear un complejo basado en PAC Nutanix.

Etapa 2. Tomamos la pila que estaba definida y escribimos scripts para la instalación automatizada y la configuración posterior para todos los subsistemas, de modo que todo se transfiriera del piloto al circuito objetivo lo más rápido posible. Todos los sistemas se implementaron en una configuración tolerante a fallas (donde esta función no se limita a las políticas con licencia del proveedor) y están conectados a los subsistemas para recopilar métricas y eventos. IB analizó el cumplimiento de sus requisitos y dio luz verde.

Etapa 3 . Migración de todos los subsistemas y su configuración al nuevo PAC. Los scripts de automatización de infraestructura se reescribieron y la migración del subsistema DSO se realizó en un modo totalmente automatizado. Las rutas de desarrollo de IS fueron recreadas por las tuberías del equipo de desarrollo.

Etapa 4. Automatización de la instalación del software de aplicación. Estas tareas fueron establecidas por los jefes de equipo de los nuevos equipos.

Etapa 5. Operación.

Acceso remoto

Los equipos de desarrollo pidieron la máxima flexibilidad para trabajar con el circuito, y el requisito de acceso remoto desde computadoras portátiles personales se estableció al comienzo del proyecto. El banco ya tenía acceso remoto, pero no era adecuado para desarrolladores. El hecho es que el esquema utilizaba una conexión de usuario a un VDI seguro. Esto era adecuado para aquellos que tenían suficiente correo y un paquete de oficina en el lugar de trabajo. Los desarrolladores necesitarían grandes clientes, de alto rendimiento, con muchos recursos. Y, por supuesto, tenían que ser estáticos, ya que la pérdida de una 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 gruesas para todos los equipos de desarrollo aumentó en gran medida el costo de la solución VDI existente.

Decidimos resolver el acceso remoto directamente a los recursos del segmento de desarrollo. Jira, Wiki, Gitlab, Nexus, montajes y stands de prueba, infraestructura virtual. Los guardias de seguridad han establecido requisitos para que el acceso se pueda organizar solo sujeto a lo siguiente:

Utilizando las tecnologías ya disponibles en el banco.
La infraestructura no debe usar controladores de dominio existentes que almacenen registros de cuentas / objetos productivos.
El acceso debe limitarse solo a los recursos requeridos por un equipo en particular (para que un equipo de un producto no pueda acceder a los recursos de otro equipo).
Máximo control sobre RBAC en 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 administra utilizando el IdM existente en el banco.

El acceso directo directo se organizó sobre la base del equipo bancario existente. El control de acceso se dividió en grupos AD, que correspondían a las reglas en los contextos (un grupo de productos = un grupo de reglas).

Administrar plantillas de VM

La velocidad de creación del circuito 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 de ejecución general de la tubería. Se consideraron dos opciones para preparar imágenes VM básicas. El primero es el tamaño mínimo de la imagen, predeterminado para todos los productos / sistemas, el cumplimiento máximo con las políticas bancarias para la configuración. La segunda es una imagen básica que contiene el software / software pesado instalado, cuyo tiempo de instalación podría afectar en gran medida la velocidad de la tubería.

Los requisitos de infraestructura y seguridad también se tuvieron en cuenta durante el desarrollo: mantener las imágenes actualizadas (parches, etc.), integración con SIEM, configuraciones de seguridad de acuerdo con los estándares adoptados por el banco.

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 instalar parches en cada imagen para nuevas versiones de software / software.

En base a los resultados, se compiló una lista del conjunto mínimo requerido de sistemas operativos, cuya actualización es realizada por el equipo operativo, y los scripts de la tubería son totalmente responsables de actualizar el software / software, y si es necesario, cambiar la versión del software instalado es suficiente para transferir la etiqueta deseada a la tubería. Sí, esto requiere escenarios de implementación más complejos del equipo de producto de Devops, pero reduce en gran medida el tiempo de funcionamiento para admitir imágenes básicas, que podrían recaer en el servicio más de cien imágenes de VM básicas.

Acceso a Internet

Otro obstáculo con la seguridad bancaria fue el acceso desde el entorno de desarrollo a los recursos de Internet. Además, este acceso se puede dividir en dos categorías:

Acceso a infraestructura.
Acceso a desarrolladores.

El acceso a la infraestructura se organizó mediante proxy de repositorios externos de Nexus. Es decir, no se proporcionó acceso directo desde máquinas virtuales. Esto hizo posible comprometerse con IS, lo que fue categóricamente contrario a proporcionar acceso al mundo exterior desde el segmento de desarrollo.

Se requería acceso a Internet para desarrolladores por razones obvias (stackoverflow). Y aunque todos los equipos, como se mencionó anteriormente, tenían acceso remoto al circuito, no siempre es conveniente cuando no puede hacer ctrl + v desde el lugar de trabajo del desarrollador en el banco en el IDE.

Se acordó con IS que inicialmente, en la etapa de prueba, se proporcionará acceso a través de un proxy bancario basado en una lista blanca. Al final del proyecto, el acceso se transferirá a la lista negra. Se prepararon enormes tablas de acceso, que indicaban los principales recursos y repositorios que necesitaban acceso al comienzo del proyecto. La coordinación de estos accesos tomó un tiempo decente, lo que nos permitió insistir en la transición más rápida a las listas negras.

resultados

El proyecto terminó hace poco menos de un año. Por extraño que parezca, pero todos los contratistas a tiempo cambiaron a la nueva pila y nadie se fue debido a la nueva automatización. IB no tiene prisa por compartir críticas positivas, pero no se queja, por lo que podemos concluir que les gusta. Los conflictos disminuyeron, porque IS nuevamente siente control, pero al mismo tiempo no interfiere con los procesos de desarrollo. Los equipos obtuvieron más responsabilidad y, en general, la actitud hacia la seguridad de la información ha mejorado. El banco entendió que la transición a DevSecOps era casi inevitable, y en mi opinión lo hizo de la manera más suave y correcta.

Alexander Shubin, arquitecto de sistemas.

DevOps vs DevSecOps: cómo se veía en un banco