Banka ua jep projektet e saj shumë kontraktorëve. "Të jashtmet" shkruajnë kodin, pastaj transmetojnë rezultatet në një formë jo shumë të përshtatshme. Konkretisht, procesi dukej kështu: ata dorëzuan një projekt që kaloi testet funksionale me ta dhe më pas u testua brenda perimetrit bankar për integrim, ngarkesë etj. Shpesh zbulohej se testet po dështonin. Pastaj gjithçka u kthye te zhvilluesi i jashtëm. Siç mund ta merrni me mend, kjo nënkuptonte kohë të gjata për rregullime të defekteve.
Banka vendosi se ishte e mundur dhe e nevojshme të tërhiqte të gjithë tubacionin nën krahun e saj, nga angazhimet deri te lirimi. Që gjithçka të jetë uniforme dhe nën kontrollin e ekipeve përgjegjëse për produktin në bankë. Kjo do të thotë, sikur kontraktori i jashtëm të ishte thjesht duke punuar diku në dhomën tjetër të zyrës. Në pirgun e korporatës. Ky është një devops i zakonshëm.
Nga erdhi Sec? Siguria e bankës ka vendosur kërkesa të larta se si një kontraktues i jashtëm mund të punojë në segmentin e rrjetit, çfarë aksesi ka dikush, si dhe kush punon me kodin. Thjesht, IB nuk e dinte ende se kur kontraktorët punojnë jashtë, ndiqen pak standarde bankare. Dhe pastaj brenda dy ditësh të gjithë duhet të fillojnë t'i vëzhgojnë ato.
Zbulimi i thjeshtë se kontraktori kishte akses të plotë në kodin e produktit tashmë e kishte kthyer botën e tyre përmbys.
Në këtë moment filloi historia e DevSecOps, për të cilën dua t'ju tregoj.
Çfarë përfundimesh praktike nxori banka nga kjo situatë?
Kishte shumë polemika për faktin se gjithçka po bëhet në mënyrë të gabuar. Zhvilluesit thanë se siguria është e zënë vetëm duke u përpjekur të ndërhyjë në zhvillim, dhe ata, si rojet, përpiqen të ndalojnë pa menduar. Nga ana tjetër, specialistët e sigurisë hezituan midis zgjedhjes midis këndvështrimeve: "zhvilluesit krijojnë dobësi në qarkun tonë" dhe "zhvilluesit nuk krijojnë dobësi, por janë ata vetë". Mosmarrëveshja do të kishte vazhduar për një kohë të gjatë nëse jo kërkesat e reja të tregut dhe shfaqja e paradigmës DevSecOps. Ishte e mundur të shpjegohej se vetë ky automatizim i proceseve duke marrë parasysh kërkesat e sigurisë së informacionit "jashtë kutisë" do t'i ndihmojë të gjithë të mbeten të lumtur. Në kuptimin që rregullat shkruhen menjëherë dhe nuk ndryshojnë gjatë lojës (siguria e informacionit nuk do të ndalojë diçka të papritur), dhe zhvilluesit e mbajnë sigurinë e informacionit të informuar për gjithçka që ndodh (siguria e informacionit nuk ndeshet me diçka papritur) . Çdo ekip është gjithashtu përgjegjës për sigurinë përfundimtare, dhe jo disa vëllezër më të mëdhenj abstraktë.
- Meqenëse punonjësit e jashtëm tashmë kanë akses në kod dhe një numër sistemesh të brendshme, ndoshta është e mundur të hiqet nga dokumentet kërkesa "zhvillimi duhet të kryhet tërësisht në infrastrukturën e bankës".
- Nga ana tjetër, ne duhet të forcojmë kontrollin mbi atë që po ndodh.
- Kompromisi ishte krijimi i ekipeve ndërfunksionale, ku punonjësit punojnë ngushtë me njerëz të jashtëm. Në këtë rast, duhet të siguroheni që ekipi të punojë me mjete në serverët e bankës. Nga fillimi deri në fund.
Kjo do të thotë, kontraktorët mund të lejohen, por atyre duhet t'u jepen segmente të veçanta. Që të mos sjellin një lloj infeksioni nga jashtë në infrastrukturën e bankës dhe që të mos shohin më shumë sesa duhet. Epo, në mënyrë që veprimet e tyre të regjistrohen. DLP për mbrojtje nga rrjedhjet, e gjithë kjo u përfshi.
Në parim, të gjitha bankat vijnë në këtë herët a vonë. Këtu shkuam në rrugën e rrahur dhe ramë dakord për kërkesat për ambiente të tilla ku funksionojnë “eksternalët”. U shfaq një gamë maksimale e mjeteve të kontrollit të aksesit, mjeteve të kontrollit të cenueshmërisë, analizave antivirus në qarqe, montime dhe teste. Kjo quhet DevSecOps.
Papritur u bë e qartë se nëse më parë siguria bankare e DevSecOps nuk kishte kontroll mbi atë që ndodh nga ana e zhvilluesit, atëherë në paradigmën e re siguria kontrollohet në të njëjtën mënyrë si ngjarjet e zakonshme në infrastrukturë. Vetëm tani ka sinjalizime për asambletë, kontrollin e bibliotekave, e kështu me radhë.
Mbetet vetëm transferimi i skuadrave në modelin e ri. Epo, krijoni infrastrukturën. Por këto janë gjëra të vogla, është si të vizatoni një buf. Në fakt ne kemi ndihmuar me infrastrukturën dhe në atë kohë proceset e zhvillimit po ndryshonin.
Çfarë ka ndryshuar
Vendosëm ta zbatonim me hapa të vegjël, sepse e kuptuam që shumë procese do të rrënoheshin dhe shumë “të jashtëm” mund të mos i përballonin kushtet e reja të punës nën mbikëqyrjen e të gjithëve.
Së pari, krijuam ekipe ndërfunksionale dhe mësuam të organizonim projekte duke marrë parasysh kërkesat e reja. Në kuptimin organizativ kemi diskutuar se çfarë procesesh. Rezultati ishte një diagram i tubacionit të montimit me të gjithë përgjegjësit.
- UNË C: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Test: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Prezantim (raportimi, komunikimi): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacionet (mirëmbajtje, menaxhim): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Rafte e zgjedhur:
- Baza e Njohurive - Konfluenca Atlasiane;
- Gjurmuesi i detyrave - Atlassian Jira;
- Depoja e objekteve - "Nexus";
- Sistemi i integrimit të vazhdueshëm - “Gitlab CI”;
- Sistemi i analizës së vazhdueshme - “SonarQube”;
- Sistemi i analizës së sigurisë së aplikacionit - “Micro Focus Fortify”;
- Sistemi i komunikimit - “GitLab Mattermost”;
- Sistemi i menaxhimit të konfigurimit - "Ansible";
- Sistemi i monitorimit - "ELK", "TICK Stack" ("InfluxData").
Ata filluan të krijonin një ekip që do të ishte gati të tërhiqte kontraktorët brenda. Ekziston një kuptim se ka disa gjëra të rëndësishme:
- Gjithçka duhet të jetë e unifikuar, të paktën kur transmetohet kodi. Sepse kishte po aq kontraktorë sa kishte shumë procese të ndryshme zhvillimi me veçoritë e tyre. Ishte e nevojshme që të gjithë të përshtateshin afërsisht në një, por me opsione.
- Ka shumë kontraktorë, dhe krijimi manual i infrastrukturës nuk është i përshtatshëm. Çdo detyrë e re duhet të fillojë shumë shpejt - domethënë, shembulli duhet të vendoset pothuajse menjëherë në mënyrë që zhvilluesit të kenë një sërë zgjidhjesh për të menaxhuar tubacionin e tyre.
Për të hedhur hapin e parë, ishte e nevojshme të kuptohej se çfarë po bëhej. Dhe ne duhej të përcaktonim se si të arrinim atje. Ne filluam duke ndihmuar në vizatimin e arkitekturës së zgjidhjes së synuar si në infrastrukturë ashtu edhe në automatizimin CI/CD. Më pas filluam të montonim këtë transportues. Na duhej një infrastrukturë, e njëjtë për të gjithë, ku të kalonin të njëjtat transportues. Ne ofruam opsione me llogaritje, mendoi banka, pastaj vendosi se çfarë do të ndërtohej dhe me çfarë fondesh.
Tjetra është krijimi i qarkut - instalimi i softuerit, konfigurimi. Zhvillimi i skripteve për vendosjen dhe menaxhimin e infrastrukturës. Më pas vjen kalimi në mbështetjen e transportuesit.
Ne vendosëm të testonim gjithçka në pilot. Interesante, gjatë pilotimit, një pirg i caktuar u shfaq në bankë për herë të parë. Ndër të tjera, një shitës vendas i njërës prej zgjidhjeve u ofrua për qëllimin e pilotit për një nisje të shpejtë. Sigurimi e njohu teksa pilotonte dhe la një përshtypje të paharrueshme. Kur vendosëm të kalonim, për fat të mirë, shtresa e infrastrukturës u zëvendësua me një zgjidhje Nutanix, e cila ishte tashmë në bankë më parë. Për më tepër, më parë ishte për VDI, por ne e ripërdornim për shërbime infrastrukturore. Në vëllime të vogla nuk përshtatej në ekonomi, por në vëllime të mëdha u bë një mjedis i shkëlqyer për zhvillim dhe testim.
Pjesa tjetër e pirgut është pak a shumë e njohur për të gjithë. U përdorën mjete automatizimi në Ansible dhe specialistët e sigurisë bashkëpunuan ngushtë me ta. Stacki i Atlassin u përdor nga banka përpara projektit. Mjetet e sigurisë Fortinet - u propozua nga vetë njerëzit e sigurisë. Korniza e testimit u krijua nga banka, pa pyetje. Sistemi i depove ngriti pyetje; më duhej të mësohesha me të.
Kontraktorëve iu dha një pirg i ri. Ata na dhanë kohë për ta rishkruar atë për GitlabCI, dhe për të migruar Jira në segmentin bankar, e kështu me radhë.
hap pas hapi
Faza 1. Së pari, ne përdorëm një zgjidhje nga një shitës vendas, produkti u lidh me një segment të ri të krijuar të rrjetit të OSSH-së. Platforma u zgjodh për kohën e dorëzimit, fleksibilitetin e shkallëzimit dhe mundësinë e automatizimit të plotë. Testet e kryera:
- Mundësia e menaxhimit fleksibël dhe plotësisht të automatizuar të infrastrukturës së platformës së virtualizimit (rrjeti, nënsistemi i diskut, nënsistemi i burimeve kompjuterike).
- Automatizimi i menaxhimit të ciklit jetësor të makinës virtuale (shabllon, fotografi, kopje rezervë).
Pas instalimit dhe konfigurimit bazë të platformës, ajo u përdor si pikë e vendosjes së nënsistemeve të fazës së dytë (veglat e DSO, skicat e zhvillimit të sistemeve të shitjes me pakicë). U krijuan grupet e nevojshme të tubacioneve - krijimi, fshirja, modifikimi, rezervimi i makinave virtuale. Këto tubacione u përdorën si faza e parë e procesit të vendosjes.
Rezultati është se pajisjet e ofruara nuk plotësojnë kërkesat e bankës për performancën dhe tolerancën e gabimeve. DIT e bankës vendosi të krijojë një kompleks të bazuar në paketën softuerike Nutanix.
Faza 2. Ne morëm grupin që u përcaktua dhe shkruam skriptet e automatizuara të instalimit dhe post-konfigurimit për të gjitha nënsistemet, në mënyrë që gjithçka të transferohej nga piloti në qarkun e synuar sa më shpejt që të ishte e mundur. Të gjitha sistemet u vendosën në një konfigurim tolerant ndaj gabimeve (ku kjo aftësi nuk kufizohet nga politikat e licencimit të shitësit) dhe u lidhën me metrikat dhe nënsistemet e mbledhjes së ngjarjeve. IB analizoi përputhshmërinë me kërkesat e saj dhe dha dritën jeshile.
Faza 3. Migrimi i të gjitha nënsistemeve dhe cilësimet e tyre në PAC të ri. Skriptet e automatizimit të infrastrukturës u rishkruan dhe migrimi i nënsistemeve të OSSH-së u përfundua në një mënyrë plotësisht të automatizuar. Konturet e zhvillimit të IP u rikrijuan nga tubacionet e ekipeve të zhvillimit.
Faza 4. Automatizimi i instalimit të softuerit të aplikacionit. Këto detyra u vendosën nga drejtuesit e ekipeve të ekipeve të reja.
Faza 5. Shfrytëzimi.
Qasje në distancë
Ekipet e zhvillimit kërkuan fleksibilitet maksimal në punën me qarkun dhe kërkesa për qasje në distancë nga laptopët personalë u ngrit që në fillim të projektit. Banka tashmë kishte akses në distancë, por nuk ishte e përshtatshme për zhvilluesit. Fakti është se skema përdori lidhjen e përdoruesit me një VDI të mbrojtur. Kjo ishte e përshtatshme për ata që kishin nevojë vetëm për postë dhe një paketë zyre në vendin e tyre të punës. Zhvilluesit do të kishin nevojë për klientë të rëndë, performancë të lartë, me shumë burime. Dhe sigurisht, ato duhej të ishin statike, pasi humbja e seancës së përdoruesit për ata që punojnë me VStudio (për shembull) ose SDK tjetër është e papranueshme. Organizimi i një numri të madh të VDI-ve të trasha statike për të gjitha ekipet e zhvillimit e rriti shumë koston e zgjidhjes ekzistuese VDI.
Ne vendosëm të punojmë për qasje në distancë direkt në burimet e segmentit të zhvillimit. Jira, Wiki, Gitlab, Nexus, grupe të ndërtimit dhe testimit, infrastrukturë virtuale. Rojet e sigurisë kanë kërkuar që qasja të mund të sigurohet vetëm në bazë të sa vijon:
- Përdorimi i teknologjive tashmë të disponueshme në bankë.
- Infrastruktura nuk duhet të përdorë kontrolluesit ekzistues të domenit që ruajnë të dhënat e objekteve të llogarisë produktive.
- Qasja duhet të kufizohet vetëm në ato burime të kërkuara nga një ekip specifik (në mënyrë që një ekip produkti të mos mund të aksesojë burimet e një ekipi tjetër).
- Kontroll maksimal mbi RBAC në sisteme.
Si rezultat, një domen i veçantë u krijua për këtë segment. Ky domen strehoi të gjitha burimet e segmentit të zhvillimit, si kredencialet e përdoruesit ashtu edhe infrastrukturën. Cikli jetësor i të dhënave në këtë fushë menaxhohet duke përdorur IdM që ekziston në bankë.
Qasja e drejtpërdrejtë në distancë u organizua në bazë të pajisjeve ekzistuese të bankës. Kontrolli i aksesit u nda në grupe AD, të cilave u korrespondonin rregullat mbi kontekstet (një grup produkti = një grup rregullash).
Menaxhimi i modelit VM
Shpejtësia e krijimit të një cikli montimi dhe testimi është një nga KPI-të kryesore të vendosura nga drejtuesi i njësisë së zhvillimit, sepse shpejtësia e përgatitjes së mjedisit ndikon drejtpërdrejt në kohën e përgjithshme të ekzekutimit të tubacionit. Janë shqyrtuar dy opsione për përgatitjen e imazheve bazë VM. E para është madhësia minimale e imazhit, e paracaktuar për të gjitha produktet e sistemit, pajtueshmëria maksimale me politikat e bankës në lidhje me cilësimet. E dyta është imazhi bazë, i cili përmban të instaluar një POPPO të rëndë, koha e instalimit të së cilës mund të ndikojë shumë në shpejtësinë e ekzekutimit të tubacionit.
Kërkesat e infrastrukturës dhe sigurisë janë marrë gjithashtu parasysh gjatë zhvillimit - mbajtja e imazheve të përditësuara (arna, etj.), integrimi me SIEM, cilësimet e sigurisë sipas standardeve të bankës.
Si rezultat, u vendos që të përdoren imazhe minimale për të minimizuar koston e mbajtjes së tyre të përditësuar. Është shumë më e lehtë të përditësosh sistemin operativ bazë sesa të rregullosh çdo imazh për versionet e reja të POPPO.
Bazuar në rezultatet, u formua një listë e grupit minimal të kërkuar të sistemeve operative, përditësimi i të cilave kryhet nga ekipi i operacioneve, dhe skriptet nga tubacioni janë plotësisht përgjegjës për përditësimin e softuerit, dhe nëse është e nevojshme, ndryshoni versionin i softuerit të instaluar - thjesht transferoni etiketën e kërkuar në tubacion. Po, kjo kërkon që ekipi i produktit devops të ketë skenarë më komplekse të vendosjes, por redukton në masë të madhe kohën operative të nevojshme për të mbështetur imazhet bazë, të cilat përndryshe mund të kërkojnë më shumë se njëqind imazhe bazë VM për t'u ruajtur.
Qasje në internet
Një tjetër pengesë me sigurinë bankare ishte aksesi në burimet e internetit nga mjedisi i zhvillimit. Për më tepër, kjo qasje mund të ndahet në dy kategori:
- Qasja në infrastrukturë.
- Qasja e zhvilluesit.
Qasja në infrastrukturë u organizua duke përfaqësuar depot e jashtme me Nexus. Kjo do të thotë, nuk u sigurua qasja e drejtpërdrejtë nga makinat virtuale. Kjo bëri të mundur arritjen e një kompromisi me sigurinë e informacionit, i cili ishte kategorikisht kundër ofrimit të çdo aksesi në botën e jashtme nga segmenti i zhvillimit.
Zhvilluesit kishin nevojë për qasje në internet për arsye të dukshme (stackoverflow). Dhe megjithëse të gjitha komandat, siç u përmend më lart, kishin qasje në distancë në qark, nuk është gjithmonë i përshtatshëm kur nuk mund të bëni ctrl+v nga vendi i punës i zhvilluesit në bankë në IDE.
U arrit një marrëveshje me IS që fillimisht, në fazën e testimit, qasja do të sigurohet përmes një përfaqësuesi bankar bazuar në një listë të bardhë. Pas përfundimit të projektit, aksesi do të transferohet në listën e zezë. U përgatitën tabela të mëdha aksesi, të cilat tregonin burimet dhe depot kryesore në të cilat kërkohej qasja në fillim të projektit. Koordinimi i këtyre akseseve mori një kohë të mjaftueshme, gjë që bëri të mundur këmbënguljen për kalimin sa më të shpejtë në listat e zeza.
Gjetjet
Projekti përfundoi pak më pak se një vit më parë. Mjaft e çuditshme, të gjithë kontraktorët kaluan në pirgun e ri në kohë dhe askush nuk u largua për shkak të automatizimit të ri. IB nuk po nxiton të ndajë reagime pozitive, por as nuk ankohet, nga ku mund të konkludojmë se u pëlqen. Konfliktet janë zbutur sepse siguria e informacionit përsëri ndihet nën kontroll, por nuk ndërhyn në proceset e zhvillimit. Ekipet iu dhanë më shumë përgjegjësi dhe qëndrimi i përgjithshëm ndaj sigurisë së informacionit u bë më i mirë. Banka e kuptoi që kalimi në DevSecOps ishte pothuajse i pashmangshëm dhe e bëri atë, për mendimin tim, në mënyrën më të butë dhe korrekte.
Alexander Shubin, arkitekt i sistemit.
Burimi: www.habr.com