Banka nodod savus projektus daudziem darbuzņēmējiem. “Ārējie” raksta kodu, pēc tam pārsūta rezultātus ne pārāk ērtā formā. Konkrēti, process izskatījās šādi: viņi kopā ar viņiem nodeva projektu, kas izturēja funkcionālos testus, un pēc tam tika pārbaudīts banku perimetrā, lai nodrošinātu integrāciju, slodzi utt. Bieži tika atklāts, ka testi bija nesekmīgi. Pēc tam viss atgriezās pie ārējā izstrādātāja. Kā jau nojaušat, tas nozīmēja ilgu izpildes laiku kļūdu labošanai.
Banka nolēma, ka ir iespējams un nepieciešams vilkt zem tās spārna visu cauruļvadu, sākot no apņemšanās līdz atbrīvošanai. Lai viss būtu vienveidīgi un bankā par preci atbildīgo brigāžu kontrolē. Tas ir, it kā ārējais darbuzņēmējs vienkārši strādātu kaut kur blakus biroja telpā. Uz korporatīvās kaudzes. Tas ir parasts devops.
No kurienes Sec nāca? Bankas drošība ir izvirzījusi augstas prasības, kā tīkla segmentā var strādāt ārējais darbuzņēmējs, kāda piekļuve kādam ir, kā un kas strādā ar kodu. Vienkārši IB vēl nezināja, ka tad, kad darbuzņēmēji strādā ārpusē, tiek ievēroti daži banku standarti. Un tad pēc pāris dienām visiem jāsāk tās novērot.
Vienkāršā atklāsme, ka darbuzņēmējam bija pilnīga piekļuve produkta kodam, jau bija apgriezusi viņu pasauli kājām gaisā.
Šajā brīdī sākās DevSecOps stāsts, par kuru es vēlos jums pastāstīt.
Kādus praktiskus secinājumus banka izdarīja no šīs situācijas?
Bija daudz strīdu par to, ka viss tiek darīts nepareizi. Izstrādātāji teica, ka drošība ir tikai aizņemta, mēģinot traucēt attīstību, un viņi, tāpat kā uzraugi, mēģina aizliegt bez domāšanas. Savukārt drošības speciālisti šaubījās, vai izvēlēties starp viedokļiem: “izstrādātāji rada ievainojamības mūsu ķēdē” un “izstrādātāji ievainojamības nerada, bet gan viņi paši ir”. Strīds būtu turpinājies ilgu laiku, ja ne jaunas tirgus prasības un DevSecOps paradigmas parādīšanās. Varēja paskaidrot, ka tieši šī procesu automatizācija, ņemot vērā informācijas drošības prasības “no kastes”, palīdzēs ikvienam palikt laimīgam. Tādā ziņā, ka noteikumi tiek pierakstīti uzreiz un spēles laikā nemainās (informācijas drošība neko negaidīti neaizliedz), un izstrādātāji informē informācijas drošību par visu, kas notiek (informācijas drošība ar kaut ko pēkšņi nesaskaras) . Katra komanda ir atbildīga arī par maksimālu drošību, nevis daži abstrakti vecāki brāļi.
- Tā kā ārējiem darbiniekiem jau ir pieeja kodam un vairākām iekšējām sistēmām, iespējams, no dokumentiem var svītrot prasību “izstrāde pilnībā jāveic bankas infrastruktūrā”.
- No otras puses, mums ir jāpastiprina kontrole pār notiekošo.
- Kompromiss bija starpfunkcionālu komandu izveide, kur darbinieki cieši sadarbojas ar ārējiem cilvēkiem. Šajā gadījumā jums ir jāpārliecinās, ka komanda strādā ar rīkiem bankas serveros. No sākuma līdz beigām.
Tas ir, darbuzņēmējus var ielaist, bet tiem ir jādod atsevišķi segmenti. Lai viņi bankas infrastruktūrā neienes kaut kādu infekciju no ārpuses un neredz vairāk, nekā nepieciešams. Nu, lai viņu darbības tiek reģistrētas. DLP aizsardzībai pret noplūdēm, tas viss bija iekļauts.
Principā visas bankas agrāk vai vēlāk nonāk pie tā. Šeit mēs gājām pa sētu ceļu un vienojāmies par prasībām tādām vidēm, kurās darbojas “ārējie”. Parādījās maksimālais piekļuves kontroles rīku klāsts, ievainojamības pārbaudes rīki, pretvīrusu analīze ķēdēs, mezglos un testos. To sauc par DevSecOps.
Pēkšņi kļuva skaidrs, ka, ja pirms DevSecOps banku drošībai nebija nekādas kontroles pār to, kas notiek izstrādātāja pusē, tad jaunajā paradigmā drošība tiek kontrolēta tāpat kā parastie notikumi infrastruktūrā. Tikai tagad ir brīdinājumi par komplektiem, bibliotēku kontroli utt.
Atliek vien pārcelt komandas uz jauno modeli. Nu, izveidojiet infrastruktūru. Bet tie ir sīkumi, tas ir kā pūces zīmēšana. Patiesībā mēs palīdzējām ar infrastruktūru, un tajā laikā attīstības procesi mainījās.
Kas ir mainījies
Nolēmām to īstenot maziem solīšiem, jo sapratām, ka daudzi procesi izjuks, un daudzi “ārējie” varētu neizturēt jaunos darba apstākļus visu uzraudzībā.
Pirmkārt, mēs izveidojām starpfunkcionālas komandas un mācījāmies organizēt projektus, ņemot vērā jaunās prasības. Organizatoriskā nozīmē apspriedām, kādi procesi. Rezultātā tika izveidota montāžas cauruļvada shēma ar visiem atbildīgajiem.
- TI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Tests: Sonarqube, SoapUI, jMeter, Selēns: MF Fortify, Performance Center, MF UFT, Ataccama.
- Iepazīstināšana (ziņošana, saziņa): Grafana, Kibana, Jira, Confluence, RocketChat.
- Darbības (apkope, vadība): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Atlasītā kaudze:
- Zināšanu bāze - Atlassian Confluence;
- Uzdevumu izsekotājs - Atlassian Jira;
- Artefaktu krātuve - “Nexus”;
- Nepārtrauktas integrācijas sistēma - “Gitlab CI”;
- Nepārtrauktas analīzes sistēma - "SonarQube";
- Lietojumprogrammu drošības analīzes sistēma - “Micro Focus Fortify”;
- Komunikācijas sistēma - “GitLab Mattermost”;
- Konfigurācijas vadības sistēma - “Ansible”;
- Monitoringa sistēma - “ELK”, “TICK Stack” (“InfluxData”).
Viņi sāka veidot komandu, kas būtu gatava vilkt iekšā darbuzņēmējus. Tiek saprasts, ka ir vairākas svarīgas lietas:
- Visam jābūt vienotam, vismaz pārsūtot kodu. Jo bija tik daudz darbuzņēmēju, cik dažādu izstrādes procesu ar savām īpatnībām. Vajadzēja visus ievietot aptuveni vienā, bet ar iespējām.
- Darbuzņēmēju ir daudz, un manuāla infrastruktūras izveide nav piemērota. Jebkurš jauns uzdevums jāsāk ļoti ātri — tas ir, gadījums ir jāizvieto gandrīz uzreiz, lai izstrādātājiem būtu pieejams risinājumu kopums sava konveijera pārvaldībai.
Lai spertu pirmo soli, bija jāsaprot, kas tiek darīts. Un mums bija jānosaka, kā tur nokļūt. Mēs sākām, palīdzot uzzīmēt mērķa risinājuma arhitektūru gan infrastruktūrā, gan CI/CD automatizācijā. Tad mēs sākām montēt šo konveijeru. Vajadzēja vienu infrastruktūru, visiem vienādu, kur kursētu vieni un tie paši konveijeri. Piedāvājām variantus ar aprēķiniem, banka domāja, tad lēma, ko un par kādiem līdzekļiem būvēs.
Tālāk seko shēmas izveide – programmatūras instalēšana, konfigurēšana. Skriptu izstrāde infrastruktūras izvietošanai un pārvaldībai. Tālāk seko pāreja uz konveijera atbalstu.
Mēs nolēmām visu pārbaudīt pilotā. Interesanti, ka pilotēšanas laikā bankā pirmo reizi parādījās noteikta steka. Cita starpā viena no risinājumiem vietējais pārdevējs tika piedāvāts izmēģinājuma darbības jomai ātrai palaišanai. Drošība viņu iepazina pilotēšanas laikā, un tas atstāja neaizmirstamu iespaidu. Kad nolēmām pāriet, par laimi, infrastruktūras slānis tika aizstāts ar Nutanix risinājumu, kas jau bija bankā iepriekš. Turklāt pirms tam tas bija paredzēts VDI, bet mēs to izmantojām atkārtoti infrastruktūras pakalpojumiem. Mazos apjomos tas neiederējās ekonomikā, bet lielos apjomos tas kļuva par lielisku vidi izstrādei un testēšanai.
Pārējā kaudze ir vairāk vai mazāk pazīstama visiem. Tika izmantoti Ansible automatizācijas rīki, un drošības speciālisti cieši sadarbojās ar tiem. Atlassin steku banka izmantoja pirms projekta. Fortinet drošības rīki – to ierosināja paši drošības cilvēki. Testēšanas rāmi izveidoja banka, jautājumi netika uzdoti. Repozitorija sistēma radīja jautājumus, man bija jāpierod.
Darbuzņēmējiem tika piešķirta jauna kaudze. Viņi deva mums laiku pārrakstīt to GitlabCI un migrēt Jira uz banku segmentu utt.
soli pa solim
Solis 1. Pirmkārt, mēs izmantojām vietējā pārdevēja risinājumu, produkts tika savienots ar jaunu izveidoto DSO tīkla segmentu. Platforma tika izvēlēta tās piegādes laika, mērogošanas elastības un pilnīgas automatizācijas iespējas dēļ. Veikti testi:
- Iespēja elastīgi un pilnībā automatizēti pārvaldīt virtualizācijas platformas infrastruktūru (tīkls, diska apakšsistēma, skaitļošanas resursu apakšsistēma).
- Virtuālās mašīnas dzīves cikla pārvaldības automatizācija (veidņu veidošana, momentuzņēmumi, dublējumkopijas).
Pēc platformas uzstādīšanas un pamata konfigurācijas tā tika izmantota kā otrā posma apakšsistēmu izvietošanas punkts (DSO rīki, mazumtirdzniecības sistēmu izstrādes izklāsts). Tika izveidoti nepieciešamie cauruļvadu komplekti - virtuālo mašīnu izveide, dzēšana, modificēšana, dublēšana. Šie cauruļvadi tika izmantoti kā pirmais izvietošanas procesa posms.
Rezultātā nodrošinātais aprīkojums neatbilst bankas prasībām attiecībā uz veiktspēju un kļūdu toleranci. Bankas DIT nolēma izveidot kompleksu, pamatojoties uz Nutanix programmatūras pakotni.
Posms 2. Mēs paņēmām definēto steku un uzrakstījām automatizētus instalēšanas un pēckonfigurācijas skriptus visām apakšsistēmām, lai viss pēc iespējas ātrāk tiktu pārsūtīts no pilotprogrammas uz mērķa ķēdi. Visas sistēmas tika izvietotas kļūdu izturīgā konfigurācijā (ja šo iespēju neierobežo piegādātāja licencēšanas politikas) un savienotas ar metrikas un notikumu apkopošanas apakšsistēmām. IB analizēja atbilstību savām prasībām un deva zaļo gaismu.
Posms 3. Visu apakšsistēmu un to iestatījumu migrācija uz jauno PAC. Infrastruktūras automatizācijas skripti tika pārrakstīti, un DSO apakšsistēmu migrācija tika pabeigta pilnībā automatizētā režīmā. IP izstrādes kontūras tika atjaunotas, izmantojot izstrādes komandu konveijeri.
Solis 4. Lietojumprogrammatūras instalēšanas automatizācija. Šos uzdevumus izvirzīja jauno komandu komandu vadītāji.
Solis 5. Ekspluatācija.
Attālā piekļuve
Izstrādes komandas pieprasīja maksimālu elastību darbā ar shēmu, un prasība par attālo piekļuvi no personīgajiem klēpjdatoriem tika izvirzīta jau projekta sākumā. Bankai jau bija attālināta piekļuve, taču tā nebija piemērota izstrādātājiem. Fakts ir tāds, ka shēma izmantoja lietotāja savienojumu ar aizsargātu VDI. Tas bija piemērots tiem, kam darba vietā bija nepieciešams tikai pasts un biroja pakete. Izstrādātājiem būtu nepieciešami smagi klienti, augsta veiktspēja, ar lieliem resursiem. Un, protams, tiem bija jābūt statiskiem, jo lietotāja sesijas zaudēšana tiem, kas strādā ar VStudio (piemēram) vai citu SDK, ir nepieņemama. Liela skaita biezu statisku VDI organizēšana visām izstrādes komandām ievērojami palielināja esošā VDI risinājuma izmaksas.
Nolēmām strādāt pie attālinātās piekļuves tieši attīstības segmenta resursiem. Jira, Wiki, Gitlab, Nexus, būvējiet un testējiet stendus, virtuālo infrastruktūru. Apsardzes darbinieki pieprasījuši, lai piekļuve tiktu nodrošināta tikai ar nosacījumu, ka:
- Izmantojot bankā jau pieejamās tehnoloģijas.
- Infrastruktūrā nevajadzētu izmantot esošos domēna kontrollerus, kas glabā produktīvu konta objektu ierakstus.
- Piekļuve jāierobežo tikai ar tiem resursiem, kas nepieciešami konkrētai komandai (lai viena produktu komanda nevarētu piekļūt citas komandas resursiem).
- Maksimāla kontrole pār RBAC sistēmās.
Rezultātā šim segmentam tika izveidots atsevišķs domēns. Šajā domēnā bija visi izstrādes segmenta resursi, gan lietotāju akreditācijas dati, gan infrastruktūra. Ierakstu dzīves cikls šajā domēnā tiek pārvaldīts, izmantojot bankā esošo IdM.
Tiešā attālinātā piekļuve tika organizēta, pamatojoties uz bankas esošo aprīkojumu. Piekļuves kontrole tika sadalīta AD grupās, kurām atbilst kontekstu noteikumi (viena produktu grupa = viena noteikumu grupa).
VM veidņu pārvaldība
Montāžas un testēšanas cilpas izveides ātrums ir viens no galvenajiem izstrādes nodaļas vadītāja noteiktajiem KPI, jo vides sagatavošanas ātrums tieši ietekmē konveijera kopējo izpildes laiku. Tika apsvērtas divas iespējas, kā sagatavot bāzes VM attēlus. Pirmais ir minimālie attēlu izmēri, pēc noklusējuma visiem sistēmas produktiem, maksimālā atbilstība bankas politikām attiecībā uz iestatījumiem. Otrais ir bāzes attēls, kurā ir uzstādīts lieljaudas POPPO, kura uzstādīšanas laiks varētu būtiski ietekmēt cauruļvada izpildes ātrumu.
Izstrādes laikā tika ņemtas vērā arī infrastruktūras un drošības prasības - attēlu atjaunināšana (ielāpi utt.), integrācija ar SIEM, drošības iestatījumi atbilstoši banku standartiem.
Rezultātā tika nolemts izmantot minimālu attēlu skaitu, lai samazinātu to atjaunināšanas izmaksas. Ir daudz vieglāk atjaunināt bāzes operētājsistēmu, nekā labot katru attēlu jaunām POPPO versijām.
Balstoties uz rezultātiem, tika izveidots saraksts ar minimāli nepieciešamo operētājsistēmu komplektu, kuras atjaunināšanu veic operāciju komanda, un skripti no konveijera ir pilnībā atbildīgi par programmatūras atjaunināšanu un, ja nepieciešams, versijas maiņu. no instalētās programmatūras — vienkārši pārsūtiet nepieciešamo tagu uz konveijeru. Jā, tas prasa, lai devops produktu komandai būtu sarežģītāki izvietošanas scenāriji, taču tas ievērojami samazina darbības laiku, kas nepieciešams bāzes attēlu atbalstam, kura uzturēšanai pretējā gadījumā varētu būt nepieciešami vairāk nekā simts pamata VM attēli.
Interneta piekļuve
Vēl viens klupšanas akmens ar banku drošību bija piekļuve interneta resursiem no izstrādes vides. Turklāt šo piekļuvi var iedalīt divās kategorijās:
- Piekļuve infrastruktūrai.
- Izstrādātāja piekļuve.
Piekļuve infrastruktūrai tika organizēta, izmantojot Nexus starpniekserveri ārējos repozitorijus. Tas ir, tieša piekļuve no virtuālajām mašīnām netika nodrošināta. Tas ļāva panākt kompromisu ar informācijas drošību, kas bija kategoriski pret jebkādas piekļuves nodrošināšanu ārpasaulei no attīstības segmenta.
Izstrādātājiem acīmredzamu iemeslu dēļ bija nepieciešama piekļuve internetam (stackoverflow). Un, lai gan visām komandām, kā minēts iepriekš, bija attāla piekļuve ķēdei, tas ne vienmēr ir ērti, ja nevarat veikt ctrl+v no izstrādātāja darba vietas IDE bankā.
Ar IS tika panākta vienošanās, ka sākotnēji, testēšanas posmā, piekļuve tiks nodrošināta, izmantojot bankas starpniekserveri, pamatojoties uz balto sarakstu. Pēc projekta pabeigšanas piekļuve tiks nodota melnajam sarakstam. Tika sagatavotas milzīgas piekļuves tabulas, kurās bija norādīti galvenie resursi un krātuves, kurām bija nepieciešama piekļuve projekta sākumā. Šo pieeju saskaņošana aizņēma diezgan daudz laika, kas ļāva uzstāt uz pēc iespējas ātrāku pāreju uz melnajiem sarakstiem.
rezultātus
Projekts noslēdzās nedaudz mazāk nekā pirms gada. Savādi, ka visi darbuzņēmēji laicīgi pārgāja uz jauno skursteni un neviens neaizbrauca jaunās automatizācijas dēļ. IB nesteidzas dalīties ar pozitīvām atsauksmēm, taču arī nesūdzas, no kā varam secināt, ka patīk. Konflikti ir mazinājušies, jo informācijas drošība atkal jūtas kontrolējama, bet netraucē attīstības procesiem. Komandām tika uzticēta lielāka atbildība, un kopējā attieksme pret informācijas drošību kļuva labāka. Banka saprata, ka pāreja uz DevSecOps ir gandrīz neizbēgama, un izdarīja to, manuprāt, vismaigākajā un pareizākajā veidā.
Aleksandrs Šubins, sistēmas arhitekts.
Avots: www.habr.com