O banco subcontrata os seus proxectos a moitos contratistas. Os "externos" escriben código e, a continuación, transmiten os resultados nunha forma non moi conveniente. En concreto, o proceso quedou así: entregaron con eles un proxecto que pasou probas funcionais, e despois probouse dentro do perímetro bancario para a súa integración, carga, etc. Moitas veces descubriuse que as probas fallaban. Entón todo volveu ao desenvolvedor externo. Como podes adiviñar, isto supuxo un longo prazo de execución de erros.
O banco decidiu que era posible e necesario arrastrar todo o gasoduto baixo a súa á, desde os compromisos ata a liberación. Para que todo sexa uniforme e baixo o control dos equipos responsables do produto no banco. É dicir, coma se o contratista externo simplemente estivese traballando nalgún lugar do cuarto próximo da oficina. Na pila corporativa. Este é un devops común.
De onde veu Sec? A seguridade do banco impuxo unha gran esixencia sobre como pode traballar un contratista externo no segmento de rede, que acceso ten alguén, como e quen traballa co código. É que IB aínda non sabía que cando os contratistas traballan fóra, se seguen poucos estándares bancarios. E logo nun par de días todo o mundo debe comezar a observalos.
A simple revelación de que o contratista tiña acceso total ao código do produto xa puxo o seu mundo patas arriba.
Neste momento comezou a historia de DevSecOps, da que quero falarvos.
Que conclusións prácticas sacou o banco desta situación?
Houbo moita polémica sobre o feito de que todo se está facendo mal. Os desenvolvedores dixeron que a seguridade só está ocupada intentando interferir co desenvolvemento, e eles, como os vixiantes, intentan prohibir sen pensalo. Pola súa banda, os especialistas en seguridade dubidaron entre escoller entre os puntos de vista: "os desenvolvedores crean vulnerabilidades no noso circuíto" e "os desenvolvedores non crean vulnerabilidades, senón que son eles mesmos". A disputa tería continuado durante moito tempo se non fose polas novas demandas do mercado e a aparición do paradigma DevSecOps. Púidose explicar que esta mesma automatización dos procesos tendo en conta os requisitos de seguridade da información "fóra da caixa" axudará a que todos sigan contentos. No sentido de que as regras se anotan inmediatamente e non cambian durante o xogo (a seguridade da información non prohibirá algo inesperadamente), e os desenvolvedores manteñen a seguridade da información informada sobre todo o que ocorre (a seguridade da información non se atopa con algo de súpeto). . Cada equipo tamén é responsable da máxima seguridade, e non duns irmáns maiores abstractos.
- Dado que os empregados externos xa teñen acceso ao código e a varios sistemas internos, probablemente sexa posible eliminar dos documentos o requisito de "o desenvolvemento debe realizarse integramente na infraestrutura do banco".
- Por outra banda, hai que reforzar o control sobre o que está a suceder.
- O compromiso foi a creación de equipos multifuncionais, onde os empregados traballan en estreita colaboración con persoas externas. Neste caso, debes asegurarte de que o equipo traballa con ferramentas nos servidores do banco. Dende o principio ata o final.
É dicir, os contratistas poden entrar, pero hai que darlles segmentos separados. Para que non traian algún tipo de infección de fóra á infraestrutura do banco e para que non vexan máis do necesario. Ben, para que se rexistren as súas accións. DLP para protección contra fugas, todo isto foi incluído.
En principio, todos os bancos chegan a iso tarde ou cedo. Aquí fomos polos camiños trillados e acordamos os requisitos para estes ambientes nos que traballan "externos". Apareceu unha gama máxima de ferramentas de control de acceso, ferramentas de comprobación de vulnerabilidades, análise de antivirus en circuítos, conxuntos e probas. Isto chámase DevSecOps.
De súpeto quedou claro que, se antes de DevSecOps a seguridade bancaria non tiña control sobre o que ocorre por parte do desenvolvedor, entón no novo paradigma a seguridade está controlada do mesmo xeito que os acontecementos ordinarios na infraestrutura. Só agora hai alertas sobre asembleas, control de bibliotecas, etc.
Só queda trasladar os equipos ao novo modelo. Ben, crea a infraestrutura. Pero estas son bagatelas, é como debuxar unha curuxa. En realidade, axudamos coa infraestrutura, e nese momento os procesos de desenvolvemento estaban cambiando.
O que cambiou
Decidimos implementalo en pequenos pasos, porque entendiamos que moitos procesos se desmoronarían, e moitos “externos” poderían non soportar as novas condicións de traballo baixo a supervisión de todos.
En primeiro lugar, creamos equipos transversais e aprendemos a organizar proxectos tendo en conta os novos requisitos. No sentido de organizativamente discutimos que procesos. O resultado foi un esquema da canalización de montaxe con todos os responsables.
- I C: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Proba: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Presentación (informes, comunicación): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacións (mantemento, xestión): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Pila seleccionada:
- Base de coñecemento - Atlassian Confluence;
- Rastreador de tarefas - Atlassian Jira;
- Repositorio de artefactos - "Nexus";
- Sistema de integración continua - "Gitlab CI";
- Sistema de análise continua - "SonarQube";
- Sistema de análise de seguridade da aplicación - "Micro Focus Fortify";
- Sistema de comunicación - "GitLab Mattermost";
- Sistema de xestión de configuración - "Ansible";
- Sistema de monitorización - "ELK", "TICK Stack" ("InfluxData").
Comezaron a crear un equipo que estaría preparado para arrastrar contratistas dentro. Hai unha conciencia de que hai varias cousas importantes:
- Todo debería estar unificado, polo menos cando se transmite código. Porque había tantos contratistas como tantos procesos de desenvolvemento diferentes coas súas propias peculiaridades. Era necesario encaixar a todos nun aproximadamente, pero con opcións.
- Hai moitos contratistas, e a creación manual de infraestrutura non é adecuada. Calquera tarefa nova debería comezar moi rapidamente, é dicir, a instancia debería despregarse case ao instante, para que os desenvolvedores teñan un conxunto de solucións para xestionar o seu pipeline.
Para dar o primeiro paso, era preciso entender o que se estaba a facer. E tivemos que determinar como chegar. Comezamos axudando a debuxar a arquitectura da solución de destino tanto en infraestruturas como na automatización de CI/CD. Despois comezamos a montar esta cinta transportadora. Necesitabamos unha infraestrutura, a mesma para todos, onde funcionaran as mesmas cintas transportadoras. Ofrecíamos opcións con cálculos, pensou o banco, despois decidiu que se construiría e con que fondos.
A continuación é a creación do circuíto - instalación de software, configuración. Desenvolvemento de scripts para a implantación e xestión de infraestruturas. A continuación vén a transición ao soporte do transportador.
Decidimos probar todo no piloto. Curiosamente, durante o pilotaxe, apareceu por primeira vez unha determinada pila no banco. Entre outras cousas, ofreceuse un provedor doméstico dunha das solucións para o alcance do piloto para un lanzamento rápido. A seguridade coñeceuno mentres pilotaba, e deixou unha impresión inesquecible. Cando decidimos cambiar, afortunadamente, a capa de infraestrutura foi substituída por unha solución Nutanix, que xa estaba no banco antes. Ademais, antes era para VDI, pero reutilizamos para servizos de infraestruturas. En pequenos volumes non encaixaba na economía, pero en grandes volumes converteuse nun excelente ambiente para o desenvolvemento e probas.
O resto da pila é máis ou menos familiar para todos. Utilizáronse ferramentas de automatización en Ansible e os especialistas en seguridade traballaron en estreita colaboración con elas. A pila Atlassin foi utilizada polo banco antes do proxecto. Ferramentas de seguridade Fortinet - foi proposto pola propia xente de seguridade. O marco de proba foi creado polo banco, sen facer preguntas. O sistema de repositorio suscitaba preguntas; tiven que afacerme.
Os contratistas recibiron unha nova pila. Déronnos tempo para reescribilo para GitlabCI e para migrar Jira ao segmento bancario, etc.
Paso a paso
Paso 1. En primeiro lugar, usamos unha solución dun provedor doméstico, o produto conectouse a un novo segmento de rede DSO creado. A plataforma escolleuse polo seu tempo de entrega, flexibilidade de escala e posibilidade de automatización total. Probas realizadas:
- Posibilidade de xestión flexible e totalmente automatizada da infraestrutura da plataforma de virtualización (rede, subsistema de discos, subsistema de recursos informáticos).
- Automatización da xestión do ciclo de vida da máquina virtual (modelos, instantáneas, copias de seguridade).
Despois da instalación e configuración básica da plataforma, utilizouse como punto de colocación dos subsistemas da segunda etapa (ferramentas DSO, esquemas de desenvolvemento de sistemas de venda polo miúdo). Creáronse os conxuntos necesarios de canalizacións: creación, eliminación, modificación, copia de seguridade de máquinas virtuais. Estes condutos foron utilizados como a primeira etapa do proceso de implantación.
O resultado é que o equipo proporcionado non cumpre os requisitos do banco de rendemento e tolerancia a fallos. O DIT do banco decidiu crear un complexo baseado no paquete de software Nutanix.
Etapa 2. Collemos a pila que se definiu e escribimos scripts de instalación e post-configuración automatizados para todos os subsistemas para que todo fose transferido do piloto ao circuíto de destino o máis rápido posible. Todos os sistemas despregáronse nunha configuración tolerante a fallos (onde esta capacidade non está limitada polas políticas de licenzas do provedor) e conectáronse a métricas e subsistemas de recollida de eventos. IB analizou o cumprimento dos seus requisitos e deu luz verde.
Etapa 3. Migración de todos os subsistemas e a súa configuración ao novo PAC. Os scripts de automatización de infraestruturas foron reescritos e a migración dos subsistemas DSO completouse nun modo totalmente automatizado. Os contornos do desenvolvemento IP foron recreados polos pipelines dos equipos de desenvolvemento.
Paso 4. Automatización da instalación de software de aplicación. Estas tarefas foron fixadas polos xefes de equipo dos novos equipos.
Paso 5. Explotación.
Acceso remoto
Os equipos de desenvolvemento pediron a máxima flexibilidade para traballar co circuíto, e a esixencia de acceso remoto desde portátiles persoais plantexouse ao comezo do proxecto. O banco xa tiña acceso remoto, pero non era apto para desenvolvedores. O caso é que o esquema utilizou a conexión do usuario a un VDI protexido. Isto era axeitado para aqueles que só necesitaban correo e un paquete de oficina no seu lugar de traballo. Os desenvolvedores necesitarían clientes pesados, de alto rendemento, con moitos recursos. E por suposto, tiñan que ser estáticos, xa que a perda da sesión de usuario para aqueles que traballan con VStudio (por exemplo) ou outro SDK é inaceptable. A organización dun gran número de VDI estáticos grosos para todos os equipos de desenvolvemento aumentou moito o custo da solución VDI existente.
Decidimos traballar no acceso remoto directamente aos recursos do segmento de desenvolvemento. Jira, Wiki, Gitlab, Nexus, bancos de construción e probas, infraestrutura virtual. Os gardas de seguridade pediron que o acceso só se poida proporcionar cos seguintes requisitos:
- Usando tecnoloxías xa dispoñibles no banco.
- A infraestrutura non debe utilizar controladores de dominio existentes que almacenan rexistros de obxectos de conta produtiva.
- O acceso debe limitarse só a aqueles recursos requiridos por un equipo específico (de xeito que un equipo de produtos non pode acceder aos recursos doutro equipo).
- Máximo control sobre RBAC nos sistemas.
Como resultado, creouse un dominio separado para este segmento. Este dominio albergaba todos os recursos do segmento de desenvolvemento, tanto as credenciais de usuario como a infraestrutura. O ciclo de vida dos rexistros deste dominio xestionase mediante o IdM existente no banco.
O acceso remoto directo organizouse en función dos equipos existentes do banco. O control de acceso dividiuse en grupos AD, aos que correspondían regras sobre contextos (un grupo de produtos = un grupo de regras).
Xestión de modelos de VM
A velocidade de creación dun bucle de montaxe e proba é un dos principais KPI establecidos polo xefe da unidade de desenvolvemento, xa que a velocidade de preparación do ambiente afecta directamente ao tempo de execución global da canalización. Consideráronse dúas opcións para preparar imaxes de VM base. O primeiro son os tamaños mínimos de imaxe, por defecto para todos os produtos do sistema, o máximo cumprimento das políticas do banco en canto á configuración. A segunda é a imaxe base, que contén un POPPO de alta resistencia instalado, cuxo tempo de instalación podería influír moito na velocidade de execución da canalización.
Durante o desenvolvemento tamén se tiveron en conta os requisitos de infraestrutura e seguridade: mantemento das imaxes actualizadas (parches, etc.), integración con SIEM, configuración de seguridade segundo os estándares bancarios.
Como resultado, decidiuse utilizar imaxes mínimas para minimizar o custo de mantelas actualizadas. É moito máis fácil actualizar o sistema operativo base que parchear cada imaxe para novas versións de POPPO.
En función dos resultados, formouse unha lista do conxunto mínimo de sistemas operativos necesarios, cuxa actualización corre a cargo do equipo de operacións, e os scripts da canalización son enteiramente responsables da actualización do software e, se é necesario, cambiar a versión. do software instalado: só tes que transferir a etiqueta requirida á canalización. Si, isto require que o equipo de produtos devops teña escenarios de implantación máis complexos, pero reduce moito o tempo operativo necesario para admitir imaxes base, que doutro xeito poderían requirir máis de cen imaxes base de VM para manter.
Acceso a Internet
Outro obstáculo coa seguridade bancaria foi o acceso aos recursos de Internet desde o entorno de desenvolvemento. Ademais, este acceso pódese dividir en dúas categorías:
- Acceso á infraestrutura.
- Acceso para programadores.
O acceso á infraestrutura organizouse mediante o proxy de repositorios externos con Nexus. É dicir, non se proporcionou o acceso directo desde as máquinas virtuais. Isto permitiu chegar a un compromiso coa seguridade da información, que se opuso categoricamente a proporcionar calquera acceso ao mundo exterior desde o segmento de desenvolvemento.
Os desenvolvedores necesitaban acceso a Internet por razóns obvias (stackoverflow). E aínda que todos os comandos, como se mencionou anteriormente, tiñan acceso remoto ao circuíto, non sempre é conveniente cando non se pode facer ctrl+v desde o lugar de traballo do programador no banco no IDE.
Chegouse a un acordo con IS que inicialmente, na fase de proba, o acceso será proporcionado a través dun proxy bancario baseado nunha lista branca. Unha vez finalizado o proxecto, o acceso pasarase á lista negra. Elaboráronse enormes táboas de acceso, nas que se indicaban os principais recursos e repositorios aos que se requiría acceso ao inicio do proxecto. A coordinación destes accesos levou moito tempo, o que permitiu insistir na transición máis rápida posible ás listas negras.
Descubrimentos
O proxecto rematou hai pouco menos dun ano. Curiosamente, todos os contratistas cambiaron á nova pila a tempo e ninguén marchou debido á nova automatización. IB non ten présa por compartir comentarios positivos, pero tampouco se queixa, polo que podemos concluír que lles gusta. Os conflitos diminuíron porque a seguridade da información volve sentirse controlada, pero non interfire nos procesos de desenvolvemento. Os equipos tiveron máis responsabilidade e a actitude xeral cara á seguridade da información mellorou. O banco entendeu que a transición a DevSecOps era case inevitable e fíxoo, na miña opinión, da forma máis suave e correcta.
Alexander Shubin, arquitecto de sistemas.
Fonte: www.habr.com