La banko subkontraktas siajn projektojn al multaj entreprenistoj. "Eksteruloj" skribas kodon, poste transdonas la rezultojn en ne tre oportuna formo. Specife, la procezo aspektis jene: ili transdonis projekton, kiu pasigis funkciajn testojn kun ili, kaj poste estis provita ene de la banka perimetro por integriĝo, ŝarĝo, ktp. Estis ofte malkovrite ke testoj malsukcesis. Tiam ĉio revenis al la ekstera programisto. Kiel vi povas supozi, ĉi tio signifis longajn tempodaŭrojn por eraroj.
La banko decidis, ke estas eble kaj necese treni la tutan dukton sub sian flugilon, de komits ĝis liberigo. Por ke ĉio estu unuforma kaj sub la kontrolo de la teamoj respondecaj pri la produkto en la banko. Tio estas, kvazaŭ la ekstera entreprenisto simple laborus ie en la apuda ĉambro de la oficejo. Sur la kompania stako. Ĉi tio estas ordinara devops.
De kie venis Sec? La sekureco de la banko metis altajn postulojn pri kiel ekstera entreprenisto povas labori en la reto-segmento, kian aliron iu havas, kiel kaj kiu laboras kun la kodo. Estas nur, ke IB ankoraŭ ne sciis, ke kiam entreprenistoj laboras ekstere, malmultaj bankaj normoj estas sekvataj. Kaj poste post kelkaj tagoj ĉiuj devas komenci observi ilin.
La simpla malkaŝo, ke la entreprenisto havis plenan aliron al la produktokodo, jam renversis ilian mondon.
En ĉi tiu momento komenciĝis la rakonto pri DevSecOps, pri kiu mi volas rakonti al vi.
Kiajn praktikajn konkludojn la banko eltiris el ĉi tiu situacio?
Estis multe da diskutado pri tio, ke ĉio estas farita en malĝusta maniero. La programistoj diris, ke sekureco estas nur okupata provante malhelpi disvolviĝon, kaj ili, kiel gardistoj, provas malpermesi sen pensi. Siavice, specialistoj pri sekureco hezitis inter elekti inter la vidpunktoj: "programistoj kreas vundeblecojn en nia cirkvito" kaj "programistoj ne kreas vundeblecojn, sed estas ili mem." La disputo daŭriĝus dum longa tempo se ne pro novaj merkatpostuloj kaj la apero de la paradigmo DevSecOps. Eblis klarigi, ke ĉi tiu sama aŭtomatigo de procezoj konsiderante informajn sekurecajn postulojn "el la skatolo" helpos ĉiujn resti feliĉaj. En la senco, ke la reguloj estas tuj skribitaj kaj ne ŝanĝiĝas dum la ludo (la informa sekureco ne malpermesos ion neatendite), kaj la programistoj informas la informan sekurecon pri ĉio, kio okazas (la informa sekureco ne renkontas ion subite) . Ĉiu teamo ankaŭ respondecas pri finfina sekureco, kaj ne iuj abstraktaj pli maljunaj fratoj.
- Ĉar eksteraj dungitoj jam havas aliron al la kodo kaj kelkaj internaj sistemoj, verŝajne estas eble forigi el la dokumentoj la postulon "evoluo devas esti farita tute sur la infrastrukturo de la banko."
- Aliflanke, ni devas plifortigi kontrolon pri tio, kio okazas.
- La kompromiso estis la kreado de transfunkciaj teamoj, kie dungitoj laboras proksime kun eksteraj homoj. En ĉi tiu kazo, vi devas certigi, ke la teamo laboras per iloj sur la serviloj de la banko. De la komenco ĝis la fino.
Tio estas, entreprenistoj povas esti permesitaj eniri, sed ili devas ricevi apartajn segmentojn. Por ke ili ne alportu ian infekton de ekstere en la infrastrukturon de la banko kaj por ke ili ne vidu pli ol kio estas necesa. Nu, por ke iliaj agoj estu registritaj. DLP por protekto kontraŭ likoj, ĉio ĉi estis inkluzivita.
Principe, ĉiuj bankoj venas al ĉi tio frue aŭ malfrue. Ĉi tie ni iris laŭ la batita vojo kaj konsentis pri la postuloj por tiaj medioj kie "eksteraj" funkcias. Aperis maksimuma gamo de alirkontrolaj iloj, vundeblaj kontrolaj iloj, kontraŭvirusa analizo sur cirkvitoj, asembleoj kaj testoj. Ĉi tio nomiĝas DevSecOps.
Subite evidentiĝis, ke se antaŭ DevSecOps banka sekureco havis neniun kontrolon pri tio, kio okazas flanke de la programisto, tiam en la nova paradigmo sekureco estas kontrolita same kiel ordinaraj eventoj sur la infrastrukturo. Nur nun estas atentigoj pri asembleoj, kontrolo de bibliotekoj ktp.
Restas nur translokigi la teamojn al la nova modelo. Nu, kreu la infrastrukturon. Sed ĉi tiuj estas bagateloj, estas kiel desegni strigon. Fakte, ni helpis pri la infrastrukturo, kaj tiutempe la evoluprocezoj ŝanĝiĝis.
Kio ŝanĝiĝis
Ni decidis efektivigi ĝin per etaj paŝoj, ĉar ni komprenis, ke multaj procezoj disfalos, kaj multaj "eksteruloj" eble ne povos elteni la novajn laborkondiĉojn sub la superrigardo de ĉiuj.
Unue, ni kreis transfunkciajn teamojn kaj lernis organizi projektojn konsiderante novajn postulojn. En la senco de organize ni diskutis kiajn procezojn. La rezulto estis diagramo de la asembleodukto kun ĉiuj respondecaj.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- KD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Testo: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- prezento (raportado, komunikado): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacioj (prizorgado, administrado): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Elektita stako:
- Knowledge Base - Atlassian Confluence;
- Taskspurilo - Atlassian Jira;
- Deponejo de artefaktoj - "Nexus";
- Kontinua integriga sistemo - "Gitlab CI";
- Kontinua analizsistemo - "SonarQube";
- Aplika sekureca analizsistemo - "Micro Focus Fortify";
- Komunikada sistemo - "GitLab Mattermost";
- Agorda administra sistemo - "Ansible";
- Monitorsistemo - "ELK", "TICK Stack" ("InfluxData").
Ili komencis krei teamon kiu estus preta treni entreprenistojn enen. Estas konstato, ke estas pluraj gravaj aferoj:
- Ĉio estu unuigita, almenaŭ dum transdono de kodo. Ĉar estis tiom da entreprenistoj kiom da diversaj evoluprocezoj kun siaj propraj proprecoj. Necesis kunigi ĉiujn en proksimume unu, sed kun ebloj.
- Estas multaj entreprenistoj, kaj mana kreado de infrastrukturo ne taŭgas. Ajna nova tasko devus komenci tre rapide - tio estas, la kazo devus esti deplojita preskaŭ tuj por ke programistoj havu aron da solvoj por administri sian dukton.
Por fari la unuan paŝon, necesis kompreni, kio estas farita. Kaj ni devis determini kiel atingi tien. Ni komencis helpante desegni la arkitekturon de la cela solvo kaj en infrastrukturo kaj CI/KD-aŭtomatigo. Tiam ni komencis kunmeti ĉi tiun transportilon. Ni bezonis unu infrastrukturon, la saman por ĉiuj, kie la samaj transportiloj kurus. Ni proponis eblojn kun kalkuloj, pensis la banko, poste decidis, kio estos konstruita kaj per kiaj financoj.
Poste estas la kreado de la cirkvito - instalado de programaro, agordo. Disvolviĝo de skriptoj por infrastruktura deplojo kaj administrado. Poste venas la transiro al transporta subteno.
Ni decidis provi ĉion sur la piloto. Kurioze, dum la pilotado, unuafoje aperis certa stako en la banko. Interalie, hejma vendisto de unu el la solvoj estis ofertita por la amplekso de la piloto por rapida lanĉo. Sekureco ekkonis lin dum li pilotas, kaj ĝi lasis neforgeseblan impreson. Kiam ni decidis ŝanĝi, feliĉe, la infrastruktura tavolo estis anstataŭigita per Nutanix-solvo, kiu jam antaŭe estis en la banko. Krome, antaŭe ĝi estis por VDI, sed ni reuzis ĝin por infrastrukturaj servoj. Ĉe malgrandaj volumoj ĝi ne kongruis en la ekonomion, sed ĉe grandaj volumoj ĝi fariĝis bonega medio por disvolviĝo kaj testado.
La resto de la stako estas pli-malpli konata al ĉiuj. Aŭtomatigaj iloj en Ansible estis uzitaj, kaj sekurecaj specialistoj laboris proksime kun ili. La Atlassin-stako estis uzita fare de la banko antaŭ la projekto. Fortinet-sekurecaj iloj - ĝi estis proponita de la sekurecaj homoj mem. La testa kadro estis kreita de la banko, neniuj demandoj faris. La deponeja sistemo levis demandojn; mi devis alkutimiĝi al ĝi.
Kontraktistoj ricevis novan stakon. Ili donis al ni tempon por reverki ĝin por GitlabCI, kaj migri Jira al la banka segmento, ktp.
Paŝon post paŝo
Etapo 1. Unue, ni uzis solvon de hejma vendisto, la produkto estis konektita al nova kreita DSO-retsegmento. La platformo estis elektita pro sia livertempo, grimpa fleksebleco kaj la ebleco de plena aŭtomatigo. Faritaj provoj:
- Eblo de fleksebla kaj plene aŭtomatigita administrado de la virtualiga platforminfrastrukturo (reto, disksubsistemo, komputikresursa subsistemo).
- Aŭtomatigo de virtuala maŝina vivciklo-administrado (ŝablono, momentfotoj, sekurkopioj).
Post instalado kaj baza agordo de la platformo, ĝi estis utiligita kiel la punkto de lokigo de la duaj fazaj subsistemoj (DSO-iloj, podetalaj sistemoj-disvolvaj skizoj). La necesaj aroj da duktoj estis kreitaj - kreado, forigo, modifo, sekurkopio de virtualaj maŝinoj. Tiuj duktoj estis utiligitaj kiel la unua fazo de la deplojprocezo.
La rezulto estas, ke la provizita ekipaĵo ne plenumas la postulojn de la banko por rendimento kaj faŭltoleremo. La DIT de la banko decidis krei komplekson bazitan sur la programaro Nutanix.
Etapo 2. Ni prenis la stakon, kiu estis difinita, kaj skribis aŭtomatigitajn instalajn kaj post-agordajn skriptojn por ĉiuj subsistemoj, por ke ĉio estu translokigita de la piloto al la celcirkvito kiel eble plej rapide. Ĉiuj sistemoj estis deplojitaj en mistolerema agordo (kie ĉi tiu kapablo ne estas limigita de la licencaj politikoj de la vendisto) kaj konektitaj al metrikoj kaj okazaĵkolektaj subsistemoj. IB analizis konformecon al siaj postuloj kaj donis la verdan lumon.
Etapo 3. Migrado de ĉiuj subsistemoj kaj iliaj agordoj al la nova PAC. Infrastrukturaj aŭtomatigmanuskriptoj estis reverkitaj, kaj la migrado de DSO-subsistemoj estis kompletigita en plene aŭtomatigita reĝimo. La konturoj de IP-evoluo estis rekreitaj per la duktoj de la evoluigaj teamoj.
Etapo 4. Aŭtomatigo de instalo de aplika programaro. Tiuj taskoj estis fiksitaj fare de la teamgvidantoj de la novaj teamoj.
Etapo 5. Ekspluatado.
Fora aliro
La evoluigteamoj petis maksimuman flekseblecon en laborado kun la cirkvito, kaj la postulo por fora aliro de personaj tekokomputiloj estis levita ĉe la komenco mem de la projekto. La banko jam havis foran aliron, sed ĝi ne estis taŭga por programistoj. Fakte, la skemo uzis la konekton de la uzanto al protektita VDI. Ĉi tio estis taŭga por tiuj, kiuj nur bezonis poŝton kaj oficejan pakaĵon ĉe sia laborejo. Programistoj bezonus pezajn klientojn, altan rendimenton, kun multaj rimedoj. Kaj kompreneble, ili devis esti senmovaj, ĉar la perdo de la uzantsesio por tiuj, kiuj laboras kun VStudio (ekzemple) aŭ alia SDK estas neakceptebla. Organizi grandan nombron da dikaj senmovaj VDIoj por ĉiuj evoluigaj teamoj multe pliigis la koston de la ekzistanta VDI-solvo.
Ni decidis labori pri fora aliro rekte al la rimedoj de la disvolva segmento. Jira, Vikio, Gitlab, Nexus, konstruaj kaj testbenkoj, virtuala infrastrukturo. Sekurgardistoj postulis, ke aliro nur povas esti disponigita kondiĉe de la sekvanta:
- Uzante teknologiojn jam disponeblajn en la banko.
- La infrastrukturo ne uzu ekzistantajn domajnajn regilojn, kiuj stokas registrojn pri produktivaj kontobjektoj.
- Aliro devus esti limigita al nur tiuj rimedoj postulitaj de specifa teamo (tiel ke unu produktteamo ne povas aliri la rimedojn de alia teamo).
- Maksimuma kontrolo de RBAC en sistemoj.
Kiel rezulto, aparta domajno estis kreita por ĉi tiu segmento. Ĉi tiu domajno enhavis ĉiujn evoluajn segmentajn rimedojn, kaj uzantajn akreditaĵojn kaj infrastrukturon. La vivociklo de rekordoj en ĉi tiu domajno estas administrita uzante la IdM ekzistantan en la banko.
Rekta fora aliro estis organizita surbaze de la ekzistanta ekipaĵo de la banko. Alirkontrolo estis dividita en AD-grupojn, al kiuj korespondis reguloj pri kuntekstoj (unu produktogrupo = unu grupo de reguloj).
VM Ŝablona Administrado
La rapideco krei kunvenan kaj testan buklon estas unu el la ĉefaj KPI-oj starigitaj de la estro de la disvolva unuo, ĉar la rapideco por prepari la medion rekte influas la ĝeneralan ekzekuttempon de la dukto. Du elektoj por prepari bazajn VM-bildojn estis pripensitaj. La unua estas la minimumaj bildaj grandecoj, defaŭlte por ĉiuj sistemaj produktoj, maksimuma plenumo de la politikoj de la banko pri agordoj. La dua estas la baza bildo, kiu enhavas pezan POPPO instalitan, kies instaltempo povus multe influi la ekzekutrapidecon de la dukto.
Dum evoluo ankaŭ estis konsiderataj postuloj pri infrastrukturo kaj sekureco - konservado de bildoj ĝisdatigitaj (pecetoj, ktp.), integriĝo kun SIEM, sekurecaj agordoj laŭ bankaj normoj.
Kiel rezulto, estis decidite uzi minimumajn bildojn por minimumigi la koston por konservi ilin ĝisdatigitaj. Estas multe pli facile ĝisdatigi la bazan OS ol fliki ĉiun bildon por novaj versioj de POPPO.
Surbaze de la rezultoj, listo estis formita de la minimuma bezonata aro de operaciumoj, kies ĝisdatigo estas farita de la operacia teamo, kaj skriptoj de la dukto estas tute respondecaj por ĝisdatigi la programaron, kaj se necese, ŝanĝi la version. de la instalita programaro - simple translokigu la bezonatan etikedon al la dukto. Jes, ĉi tio postulas, ke la devops-produkta teamo havu pli kompleksajn deplojajn scenarojn, sed ĝi multe reduktas la funkcian tempon necesan por subteni bazajn bildojn, kiuj alie povus postuli pli ol cent bazajn VM-bildojn por konservi.
Aliro al la Interreto
Alia falilo kun banka sekureco estis aliro al Interretaj rimedoj de la evolumedio. Krome, ĉi tiu aliro povas esti dividita en du kategoriojn:
- Aliro al infrastrukturo.
- Aliro por programistoj.
Infrastrukturaliro estis organizita prokurante eksterajn deponejojn kun Nexus. Tio estas, rekta aliro de virtualaj maŝinoj ne estis disponigita. Ĉi tio ebligis atingi kompromison kun informa sekureco, kiu kategorie kontraŭis havigi ajnan aliron al la ekstera mondo de la disvolva segmento.
Programistoj bezonis aliron al Interreto pro evidentaj kialoj (stackoverflow). Kaj kvankam ĉiuj komandoj, kiel menciite supre, havis foran aliron al la cirkvito, ĝi ne ĉiam konvenas kiam vi ne povas fari ctrl+v de la laborejo de la programisto en la banko en la IDE.
Interkonsento estis atingita kun IS, ke komence, en la testa stadio, aliro estos provizita per banka prokurilo bazita sur blanka listo. Post kompletigo de la projekto, aliro estos transdonita al la nigra listo. Grandegaj alirtabloj estis preparitaj, kiuj indikis la ĉefajn rimedojn kaj deponejojn al kiuj aliro estis postulata ĉe la komenco de la projekto. Kunordigo de tiuj aliroj prenis konsiderindan tempon, kio ebligis insisti pri la plej rapida ebla transiro al nigraj listoj.
Результаты
La projekto finiĝis antaŭ iom malpli ol unu jaro. Sufiĉe strange, ĉiuj entreprenistoj ŝanĝis al la nova stako ĝustatempe kaj neniu foriris pro la nova aŭtomatigo. IB ne rapidas dividi pozitivajn reagojn, sed ankaŭ ne plendas, el kio ni povas konkludi, ke ili ŝatas ĝin. Konfliktoj trankviliĝis ĉar informa sekureco denove sentas kontrolon, sed ne malhelpas evoluajn procezojn. La teamoj ricevis pli da respondeco, kaj la totala sinteno al informa sekureco iĝis pli bona. La banko komprenis, ke la transiro al DevSecOps estis preskaŭ neevitebla, kaj faris ĝin, laŭ mi, en la plej milda kaj ĝusta maniero.
Alexander Shubin, sistemarkitekto.
fonto: www.habr.com