Bankinn útvistar verkefnum sínum til margra verktaka. „Ytri“ skrifa kóða, sendu síðan niðurstöðurnar á ekki mjög þægilegu formi. Nánar tiltekið leit ferlið svona út: þeir afhentu verkefni sem stóðst virknipróf með þeim og var síðan prófað innan bankasviðsins fyrir samþættingu, álag og svo framvegis. Oft kom í ljós að próf féllu. Síðan fór allt aftur til ytri verktaki. Eins og þú getur giskað á þýddi þetta langan leiðtíma fyrir villuleiðréttingar.
Bankinn ákvað að mögulegt og nauðsynlegt væri að draga alla leiðsluna undir sinn verndarvæng, frá skuldbindingum til losunar. Þannig að allt sé einsleitt og undir stjórn þeirra teyma sem bera ábyrgð á vörunni í bankanum. Það er eins og ytri verktaki væri einfaldlega að vinna einhvers staðar í næsta herbergi skrifstofunnar. Á fyrirtækjastokknum. Þetta er venjulegt devops.
Hvaðan kom Sec? Öryggi bankans hefur gert miklar kröfur um hvernig utanaðkomandi verktaki getur unnið í nethlutanum, hvaða aðgang einhver hefur, hvernig og hver vinnur með kóðann. Það er bara að IB vissi ekki enn að þegar verktakar vinna úti er fáum bankastöðlum fylgt. Og svo eftir nokkra daga þurfa allir að byrja að fylgjast með þeim.
Sú einfalda opinberun að verktakinn hefði fullan aðgang að vörukóðanum hafði þegar sett heiminn á hvolf.
Á þessari stundu byrjaði sagan af DevSecOps, sem ég vil segja ykkur frá.
Hvaða raunhæfu ályktanir dró bankinn af þessu ástandi?
Miklar deilur urðu um að allt sé gert á rangan hátt. Hönnuðir sögðu að öryggi væri aðeins upptekið við að reyna að trufla þróun og þeir, eins og varðmenn, reyna að banna án þess að hugsa. Aftur á móti hikuðu öryggissérfræðingar á milli þess að velja á milli sjónarmiðanna: „hönnuðir búa til veikleika í hringrásinni okkar“ og „hönnuðir búa ekki til veikleika, heldur eru þeir sjálfir. Deilan hefði haldið áfram í langan tíma ef ekki hefði verið fyrir nýjar kröfur á markaði og tilkomu DevSecOps hugmyndafræðinnar. Það var hægt að útskýra að einmitt þessi sjálfvirkni ferla sem tekur mið af kröfum um upplýsingaöryggi „úr kassanum“ mun hjálpa öllum að vera ánægðir. Í þeim skilningi að reglurnar eru skrifaðar niður strax og breytast ekki meðan á leiknum stendur (upplýsingaöryggið mun ekki banna eitthvað óvænt), og þróunaraðilar halda upplýsingaörygginu upplýstu um allt sem gerist (upplýsingaöryggið lendir ekki í einhverju skyndilega) . Hvert lið ber einnig ábyrgð á fullkomnu öryggi, en ekki sumir óhlutbundnir eldri bræður.
- Þar sem utanaðkomandi starfsmenn hafa nú þegar aðgang að kóðanum og fjölda innri kerfa er líklega hægt að fjarlægja úr skjölunum kröfuna „Þróun verður að fara fram alfarið á innviðum bankans“.
- Á hinn bóginn þurfum við að efla eftirlit með því sem er að gerast.
- Málamiðlunin var stofnun þverfaglegra teyma þar sem starfsmenn vinna náið með utanaðkomandi fólki. Í þessu tilviki þarftu að ganga úr skugga um að teymið vinni á verkfærum á netþjónum bankans. Frá upphafi til enda.
Það er að segja að það er hægt að hleypa verktökum inn en þeir þurfa að fá aðskilda hluta. Svo að þeir komi ekki með einhvers konar sýkingu utan frá inn í innviði bankans og sjái ekki meira en nauðsynlegt er. Jæja, svo að aðgerðir þeirra séu skráðar. DLP til varnar gegn leka, allt þetta var innifalið.
Í grundvallaratriðum koma allir bankar að þessu fyrr eða síðar. Hér fórum við troðnar slóðir og komum okkur saman um kröfur um slíkt umhverfi þar sem „ytri“ vinna. Þar birtist hámarksúrval af aðgangsstýringartækjum, veikleikaathugunarverkfærum, vírusvarnargreiningu á rafrásum, samsetningum og prófunum. Þetta er kallað DevSecOps.
Skyndilega varð ljóst að ef áður DevSecOps bankaöryggi hafði enga stjórn á því sem gerist á hlið þróunaraðila, þá er í nýju hugmyndafræðinni stjórnað öryggi á sama hátt og venjulegum atburðum á innviðum. Aðeins núna eru tilkynningar um samkomur, eftirlit með bókasöfnum og svo framvegis.
Það eina sem er eftir er að færa liðin yfir á nýju módelið. Jæja, búðu til innviðina. En þetta eru smáræði, þetta er eins og að teikna uglu. Reyndar hjálpuðum við til við innviðina og á þeim tíma voru þróunarferlar að breytast.
Hvað hefur breyst
Við ákváðum að innleiða það í litlum skrefum, vegna þess að við áttum okkur á því að mörg ferli myndu falla í sundur og margir „ytri“ gætu ekki staðist nýju vinnuskilyrðin undir eftirliti allra.
Í fyrsta lagi stofnuðum við þvervirk teymi og lærðum að skipuleggja verkefni með hliðsjón af nýjum kröfum. Í skilningi skipulagslega ræddum við hvaða ferla. Niðurstaðan var skýringarmynd af samsetningarleiðslunni með öllum ábyrgðarmönnum.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- Geisladiskur: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Próf: Sonarqube, SoapUI, jMeter, Selen: MF Fortify, Performance Center, MF UFT, Ataccama.
- Kynning (skýrslur, samskipti): Grafana, Kibana, Jira, Confluence, RocketChat.
- aðgerðir (viðhald, stjórnun): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF þjónustustjóri, Jira, Confluence, MS Project.
Valinn stafli:
- Þekkingargrunnur - Atlassian Confluence;
- Verkefnaeftirlit - Atlassian Jira;
- Artifact geymsla - „Nexus“;
- Stöðugt samþættingarkerfi - "Gitlab CI";
- Stöðugt greiningarkerfi - „SonarQube“;
- Öryggisgreiningarkerfi forrita - „Micro Focus Fortify“;
- Samskiptakerfi - „GitLab Mattermost“;
- Stillingarstjórnunarkerfi - "Ansible";
- Vöktunarkerfi - "ELK", "TICK Stack" ("InfluxData").
Þeir byrjuðu að búa til teymi sem væri tilbúið að draga verktaka inn. Það er ljóst að það eru nokkrir mikilvægir hlutir:
- Allt ætti að vera sameinað, að minnsta kosti þegar þú sendir kóða. Vegna þess að það voru jafn margir verktakar og það voru svo mörg mismunandi þróunarferli með eigin sérkenni. Það var nauðsynlegt að passa alla í um það bil einn, en með valmöguleikum.
- Það eru margir verktakar og handvirk gerð innviða hentar ekki. Sérhvert nýtt verkefni ætti að byrja mjög fljótt - það er, tilvikið ætti að vera dreift nánast samstundis þannig að verktaki hafi sett af lausnum til að stjórna leiðslunni sinni.
Til að taka fyrsta skrefið var nauðsynlegt að skilja hvað var verið að gera. Og við urðum að ákveða hvernig við kæmumst þangað. Við byrjuðum á því að hjálpa til við að teikna arkitektúr marklausnarinnar bæði í innviðum og CI/CD sjálfvirkni. Svo fórum við að setja saman þetta færiband. Við þurftum einn innviði, eins fyrir alla, þar sem sömu færiböndin myndu ganga. Við buðum upp á valkosti með útreikningum, hugsaði bankinn, ákvað síðan hvað yrði byggt og með hvaða fjármunum.
Næst er stofnun hringrásarinnar - uppsetning hugbúnaðar, stillingar. Þróun handrita fyrir uppsetningu og stjórnun innviða. Næst kemur umskipti yfir í færibandastuðning.
Við ákváðum að prófa allt á flugmanninum. Athyglisvert er að við flugnámið birtist ákveðinn stafli í bankanum í fyrsta skipti. Meðal annars var boðið upp á innlendan söluaðila einnar lausnanna í umfangi tilraunaverkefnisins til skjótrar sjósetningar. Öryggiseftirlitið kynntist honum þegar hann stýrði og það skildi eftir sig ógleymanlegan svip. Þegar við ákváðum að skipta, sem betur fer, var innviðalaginu skipt út fyrir Nutanix lausn sem var þegar í bankanum áður. Þar að auki, áður var það fyrir VDI, en við endurnotuðum það fyrir innviðaþjónustu. Í litlu magni passaði það ekki inn í hagkerfið, en í miklu magni varð það frábært umhverfi fyrir þróun og prófanir.
Það sem eftir er af staflanum er meira og minna kunnugt öllum. Sjálfvirkniverkfæri í Ansible voru notuð og öryggissérfræðingar unnu náið með þeim. Atlassin staflan var notaður af bankanum fyrir verkefnið. Fortinet öryggistól - það var lagt til af öryggisfólkinu sjálfu. Prófunarramminn var búinn til af bankanum, engar spurningar spurðar. Geymslukerfið vakti spurningar; ég varð að venjast því.
Verktakar fengu nýjan stafla. Þeir gáfu okkur tíma til að endurskrifa það fyrir GitlabCI og flytja Jira yfir í bankahlutann og svo framvegis.
skref fyrir skref
Skref 1. Í fyrsta lagi notuðum við lausn frá innlendum söluaðila, varan var tengd við nýtt búið DSO netkerfi. Pallurinn var valinn vegna afhendingartíma hans, sveigjanleika í stærðarstærð og möguleika á fullri sjálfvirkni. Framkvæmd próf:
- Möguleiki á sveigjanlegri og fullkomlega sjálfvirkri stjórnun á innviðum sýndarvæðingarvettvangsins (netkerfi, undirkerfi diska, undirkerfi tölvuauðlinda).
- Sjálfvirkni líftímastjórnunar sýndarvéla (sniðmát, skyndimyndir, afrit).
Eftir uppsetningu og grunnstillingu vettvangsins var hann notaður sem staðsetningarpunktur annars stigs undirkerfa (DSO verkfæri, útlínur smásölukerfisþróunar). Nauðsynleg sett af leiðslum voru búin til - sköpun, eyðing, breyting, öryggisafrit af sýndarvélum. Þessar leiðslur voru notaðar sem fyrsta stig dreifingarferlisins.
Niðurstaðan er sú að útgefinn búnaður uppfyllir ekki kröfur bankans um frammistöðu og bilanaþol. DIT bankans ákvað að búa til flókið byggt á Nutanix hugbúnaðarpakkanum.
Stig 2. Við tókum staflann sem var skilgreindur og skrifuðum sjálfvirka uppsetningar- og eftirstillingarskriftir fyrir öll undirkerfi þannig að allt var flutt frá flugmanninum yfir í markrásina eins fljótt og auðið var. Öll kerfi voru sett upp í villuþolinni uppsetningu (þar sem þessi möguleiki er ekki takmörkuð af leyfisstefnu seljanda) og tengd við mælikvarða og viðburðasöfnunar undirkerfi. IB greindi hvort farið væri að kröfum sínum og gaf grænt ljós.
Stig 3. Flutningur allra undirkerfa og stillinga þeirra yfir í nýja PAC. Innviða sjálfvirkni forskriftir voru endurskrifaðar og flutningi DSO undirkerfa var lokið á fullkomlega sjálfvirkan hátt. Útlínur IP þróunar voru endurskapaðar með leiðslum þróunarteymanna.
Skref 4. Sjálfvirkni uppsetningar hugbúnaðar. Þessi verkefni voru sett af liðsstjórum nýju teymanna.
Skref 5. Hagnýting.
Fjaraðgangur
Þróunarteymin báðu um hámarks sveigjanleika í að vinna með hringrásina og krafan um fjaraðgang frá persónulegum fartölvum var borin upp strax í upphafi verkefnisins. Bankinn hafði þegar fjaraðgang, en hann hentaði ekki hönnuðum. Staðreyndin er sú að kerfið notaði tengingu notandans við verndað VDI. Þetta hentaði þeim sem vantaði bara póst og skrifstofupakka á vinnustað sínum. Hönnuðir þyrftu þunga viðskiptavini, mikla afköst, með mikið fjármagn. Og auðvitað urðu þeir að vera kyrrstæðir, þar sem tap á notendalotunni fyrir þá sem vinna með VStudio (til dæmis) eða öðrum SDK er óviðunandi. Að skipuleggja mikinn fjölda af þykkum kyrrstæðum VDI fyrir öll þróunarteymi jók verulega kostnaðinn við núverandi VDI lausn.
Við ákváðum að vinna að fjaraðgangi beint að auðlindum þróunarhluta. Jira, Wiki, Gitlab, Nexus, smíða og prófa bekki, sýndarinnviðir. Öryggisverðir hafa krafist þess að aðgangur sé einungis veittur með fyrirvara um eftirfarandi:
- Notkun tækni sem þegar er til í bankanum.
- Uppbyggingin ætti ekki að nota núverandi lénsstýringar sem geyma skrár yfir afkastamikla reikningshluti.
- Aðgangur ætti að vera takmarkaður við aðeins þau tilföng sem tiltekið teymi krefst (svo að eitt vöruteymi geti ekki fengið aðgang að tilföngum annars liðs).
- Hámarks stjórn á RBAC í kerfum.
Fyrir vikið var sérstakt lén búið til fyrir þennan hluta. Þetta lén hýsti öll auðlindir þróunarhluta, bæði notendaskilríki og innviði. Lífsferli gagna á þessu léni er stjórnað með því að nota auðkennið sem er til í bankanum.
Beinn fjaraðgangur var skipulagður á grundvelli núverandi búnaðar bankans. Aðgangsstýringu var skipt í AD hópa sem reglur um samhengi samsvaruðu (einn vöruflokkur = einn hópur reglna).
VM sniðmátsstjórnun
Hraðinn við að búa til samsetningar- og prófunarlykkju er einn af helstu KPI sem settur er af yfirmanni þróunareiningar, vegna þess að hraði undirbúa umhverfið hefur bein áhrif á heildarframkvæmdartíma leiðslunnar. Tveir möguleikar til að útbúa grunn VM myndir voru skoðaðar. Í fyrsta lagi eru lágmarksmyndastærðir, sjálfgefið fyrir allar kerfisvörur, hámarks samræmi við reglur bankans varðandi stillingar. Önnur er grunnmyndin, sem inniheldur uppsettan uppsettan uppsettan POPPO, en uppsetningartími hans gæti haft mikil áhrif á hraða leiðslunnar.
Innviða- og öryggiskröfur voru einnig teknar til greina við þróun - að halda myndum uppfærðum (plástra o.s.frv.), samþættingu við SIEM, öryggisstillingar samkvæmt bankastöðlum.
Í kjölfarið var ákveðið að nota lágmarksmyndir til að lágmarka kostnað við að halda þeim uppfærðum. Það er miklu auðveldara að uppfæra grunnstýrikerfið en að laga hverja mynd fyrir nýjar útgáfur af POPPO.
Byggt á niðurstöðunum var myndaður listi yfir lágmarks tilskilið sett af stýrikerfum, uppfærsla þeirra fer fram af rekstrarteyminu og forskriftir úr leiðslunni bera alfarið ábyrgð á uppfærslu hugbúnaðarins og ef nauðsyn krefur, breyta útgáfunni. af uppsettum hugbúnaði - flyttu bara tilskilið merki yfir á leiðsluna. Já, þetta krefst þess að vöruteymi devops sé með flóknari uppsetningaratburðarás, en það dregur verulega úr rekstrartímanum sem þarf til að styðja við grunnmyndir, sem annars gæti þurft meira en hundrað grunnmyndir af VM til að viðhalda.
internet aðgangur
Annar ásteytingarsteinn með bankaöryggi var aðgangur að internetauðlindum úr þróunarumhverfinu. Þar að auki má skipta þessum aðgangi í tvo flokka:
- Aðgangur að innviðum.
- Aðgangur þróunaraðila.
Aðgangur að innviðum var skipulagður með umboði ytri geymslum með Nexus. Það er, bein aðgangur frá sýndarvélum var ekki veittur. Þetta gerði það að verkum að hægt var að ná málamiðlun með upplýsingaöryggi, sem var afdráttarlaust gegn því að veita aðgang að umheiminum frá þróunarhlutanum.
Hönnuðir þurftu aðgang að internetinu af augljósum ástæðum (stackoverflow). Og þó allar skipanir, eins og getið er hér að ofan, hafi fjaraðgang að hringrásinni, þá er það ekki alltaf þægilegt þegar þú getur ekki gert ctrl+v frá vinnustað þróunaraðila í bankanum í IDE.
Samkomulag náðist við IS um að upphaflega, á prófunarstigi, verði aðgangur veittur í gegnum bankaumboð sem byggist á hvíta lista. Að verkefninu loknu færist aðgangur á svarta listann. Útbúnar voru risastórar aðgangstöflur sem sýndu helstu auðlindir og geymslur sem aðgangur þurfti að við upphaf verkefnisins. Samræming þessara aðganga tók talsverðan tíma, sem gerði það að verkum að hægt var að krefjast þess að skipta yfir í svartan lista sem hraðast.
Niðurstöður
Verkefninu lauk fyrir tæpu ári síðan. Merkilegt nokk skiptu allir verktakar yfir í nýja stafla á réttum tíma og enginn fór vegna nýju sjálfvirkninnar. IB er ekkert að flýta sér að deila jákvæðum viðbrögðum, en kvartar ekki heldur, af því getum við dregið þá ályktun að þeim líkar það. Átök hafa minnkað vegna þess að upplýsingaöryggi finnst aftur vera við stjórnvölinn, en truflar ekki þróunarferla. Teymin fengu aukna ábyrgð og heildarviðhorf til upplýsingaöryggis varð betra. Bankinn skildi að umskiptin yfir í DevSecOps voru nánast óumflýjanleg og gerði það að mínu mati á hinn mildasta og réttasta hátt.
Alexander Shubin, kerfisarkitekt.
Heimild: www.habr.com