Pank tellib oma projektid paljudelt töövõtjatelt. “Välised” kirjutavad koodi ja edastavad seejärel tulemused mitte eriti mugaval kujul. Täpsemalt nägi protsess välja selline: nad andsid üle projekti, mis läbis nendega koos funktsionaalsed testid, ja seejärel testiti panganduse perimeetri sees integratsiooni, koormuse jms osas. Sageli avastati, et testid ebaõnnestusid. Seejärel läks kõik tagasi välisele arendajale. Nagu võite arvata, tähendas see veaparanduste jaoks pikki teostusaega.
Pank otsustas, et on võimalik ja vajalik tõmmata oma tiiva alla kogu torujuhe, kohustustest vabastamiseni. Et kõik oleks ühtlane ja pangas toote eest vastutavate meeskondade kontrolli all. See tähendab, nagu töötaks välistöövõtja lihtsalt kuskil kontori kõrvalruumis. Ettevõtte stackil. See on tavaline devops.
Kust Sec tuli? Panga turvalisus on seadnud kõrged nõudmised sellele, kuidas väline töövõtja saab võrgusegmendis töötada, milline juurdepääs kellelgi on, kuidas ja kes koodiga töötab. Lihtsalt IB ei teadnud veel, et kui töövõtjad töötavad väljaspool, järgitakse väheseid pangandusstandardeid. Ja siis paari päeva pärast peavad kõik neid jälgima hakkama.
Lihtne ilmutus, et töövõtjal oli täielik juurdepääs tootekoodile, oli nende maailma juba pea peale pööranud.
Sel hetkel sai alguse DevSecOpsi lugu, millest tahan teile rääkida.
Milliseid praktilisi järeldusi pank sellest olukorrast tegi?
Palju vaieldi selle üle, et kõike tehakse valesti. Arendajad ütlesid, et turvalisus tegeleb vaid sellega, et üritab arengusse sekkuda ja nemad, nagu valvurid, üritavad mõtlemata keelata. Turvaspetsialistid omakorda kõhklesid, kas valida seisukohtade vahel: "arendajad loovad meie vooluringis turvaauke" ja "arendajad ei loo turvaauke, vaid on nad ise." Vaidlus oleks kestnud pikka aega, kui mitte uusi turunõudmisi ja DevSecOpsi paradigma esilekerkimist. Selgitada oli võimalik, et just selline infoturbe nõudeid arvestav protsesside automatiseerimine “kastist väljas” aitab kõigil õnnelikuks jääda. Selles mõttes, et reeglid kirjutatakse kohe kirja ja mängu käigus ei muutu (infoturve ei keela midagi ootamatult) ning arendajad hoiavad infoturbe kursis kõigega, mis toimub (infoturve ei puutu midagi ootamatult kokku) . Iga meeskond vastutab ka ülima ohutuse eest, mitte mingid abstraktsed vanemad vennad.
- Kuna välistöötajatel on juba ligipääs koodile ja mitmele sisemisele süsteemile, on tõenäoliselt võimalik dokumentidest eemaldada nõue "arendus peab toimuma täielikult panga infrastruktuuril".
- Teisest küljest peame tugevdama kontrolli toimuva üle.
- Kompromissiks oli funktsionaalsete meeskondade loomine, kus töötajad teevad tihedat koostööd väliste inimestega. Sel juhul peate veenduma, et meeskond töötab panga serverites olevate tööriistadega. Algusest lõpuni.
See tähendab, et töövõtjaid võib sisse lasta, kuid neile tuleb anda eraldi segmendid. Et nad ei tooks väljastpoolt mingit nakkust panga infrastruktuuri ja et nad ei näeks rohkem kui vaja. Noh, et nende tegevus logitakse. DLP kaitseks lekete eest, see kõik oli kaasas.
Põhimõtteliselt jõuavad kõik pangad varem või hiljem selleni. Siin läksime mööda käidud teed ja leppisime kokku nõuded sellistele keskkondadele, kus "välis" töötab. Ilmus maksimaalne valik juurdepääsukontrolli tööriistu, haavatavuse kontrollimise tööriistu, ahelate, sõlmede ja testide viirusetõrjeanalüüsi. Seda nimetatakse DevSecOpsiks.
Järsku sai selgeks, et kui enne DevSecOpsi pangandusturvalisusel ei olnud kontrolli arendaja poolel toimuva üle, siis uues paradigmas kontrollitakse turvalisust samamoodi nagu tavalisi sündmusi taristul. Alles nüüd on märguanded koostude, raamatukogude kontrolli jms kohta.
Jääb vaid meeskonnad uuele mudelile üle viia. Noh, looge infrastruktuur. Kuid need on pisiasjad, see on nagu öökulli joonistamine. Tegelikult aitasime taristuga ja sel ajal olid arendusprotsessid muutumas.
Mis on muutunud
Otsustasime selle ellu viia väikeste sammude kaupa, sest saime aru, et paljud protsessid lagunevad ja paljud “välised” ei pruugi uutes töötingimustes kõigi järelevalve all vastu pidada.
Esiteks lõime funktsionaalsed meeskonnad ja õppisime projekte korraldama uusi nõudeid arvestades. Organisatsioonilises mõttes arutasime, millised protsessid. Tulemuseks oli montaažitorustiku skeem koos kõigi vastutavatega.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Test: Sonarqube, SoapUI, jMeter, seleen: MF Fortify, Performance Center, MF UFT, Ataccama.
- Esitlus (aruandlus, suhtlus): Grafana, Kibana, Jira, Confluence, RocketChat.
- Operations (hooldus, haldamine): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Valitud virn:
- Teadmistebaas – Atlassi ühinemiskoht;
- Ülesande jälgija - Atlassian Jira;
- Artefaktide hoidla - "Nexus";
- Pidev integratsioonisüsteem - “Gitlab CI”;
- Pideva analüüsi süsteem - "SonarQube";
- Rakenduste turvaanalüüsi süsteem - “Micro Focus Fortify”;
- Sidesüsteem - “GitLab Mattermost”;
- Konfiguratsioonihaldussüsteem - "Ansible";
- Seiresüsteem - “ELK”, “TICK Stack” (“InfluxData”).
Nad hakkasid looma meeskonda, kes oleks valmis töövõtjaid sisse tõmbama. Mõistetakse, et on mitmeid olulisi asju:
- Kõik peaks olema ühtne, vähemalt koodi edastamisel. Sest nii palju oli töövõtjaid, kui palju oli erinevaid oma eripäradega arendusprotsesse. Kõik oli vaja mahutada ligikaudu ühte, kuid valikutega.
- Töövõtjaid on palju ja infrastruktuuri käsitsi loomine ei sobi. Iga uus ülesanne peaks algama väga kiiresti – see tähendab, et eksemplar tuleks juurutada peaaegu kohe, et arendajatel oleks lahendusi oma konveieri haldamiseks.
Esimese sammu tegemiseks oli vaja aru saada, mida tehakse. Ja me pidime otsustama, kuidas sinna jõuda. Alustasime sellest, et aitasime joonistada sihtlahenduse arhitektuuri nii infrastruktuuris kui ka CI/CD automatiseerimises. Siis hakkasime seda konveieri kokku panema. Meil oli vaja ühte infrastruktuuri, kõigile ühte ja samad konveierid. Pakkusime variante koos arvutustega, pank mõtles, siis otsustas, mida ja milliste vahenditega ehitatakse.
Järgmine on vooluringi loomine - tarkvara installimine, seadistamine. Skriptide arendamine infrastruktuuri juurutamiseks ja haldamiseks. Järgmisena tuleb üleminek konveieri toele.
Otsustasime katsetada kõike piloodil. Huvitaval kombel tekkis piloteerimisel esimest korda panka teatud stäkk. Muuhulgas pakuti ühe lahenduse kodumaist müüjat pilootprojekti kiireks käivitamiseks. Turvalisus õppis teda piloodi ajal tundma ja see jättis unustamatu mulje. Kui otsustasime vahetada, siis õnneks asendati taristukiht Nutanixi lahendusega, mis oli juba varem pangas. Veelgi enam, enne seda oli see VDI jaoks, kuid kasutasime seda uuesti infrastruktuuriteenuste jaoks. Väikeste mahtude puhul see majandusse ei mahtunud, kuid suurte mahtude juures sai sellest suurepärane arendus- ja testimiskeskkond.
Ülejäänud stäkk on enam-vähem kõigile tuttav. Kasutati Ansible'i automatiseerimistööriistu ja turvaspetsialistid tegid nendega tihedat koostööd. Atlassini virna kasutas pank enne projekti. Fortineti turvatööriistad – selle pakkusid välja turvainimesed ise. Testimisraami lõi pank, küsimusi ei esitatud. Repositoorium tekitas küsimusi, ma pidin sellega harjuma.
Töövõtjatele anti uus virn. Nad andsid meile aega, et see GitlabCI jaoks ümber kirjutada ja Jira pangandussegmenti üle viia ja nii edasi.
Samm sammu haaval
Samm 1. Esmalt kasutasime kodumaise müüja lahendust, toode ühendati uue loodud DSO võrgusegmendiga. Platvorm valiti selle tarneaja, skaleerimise paindlikkuse ja täieliku automatiseerimise võimaluse tõttu. Läbiviidud testid:
- Virtualiseerimisplatvormi infrastruktuuri (võrk, ketta alamsüsteem, arvutusressursside alamsüsteem) paindliku ja täisautomaatse haldamise võimalus.
- Virtuaalse masina elutsükli haldamise automatiseerimine (mallid, hetktõmmised, varukoopiad).
Pärast installimist ja platvormi põhikonfiguratsiooni kasutati seda teise etapi alamsüsteemide (DSO tööriistad, jaemüügisüsteemide arenduskontuurid) paigutuspunktina. Loodi vajalikud torujuhtmete komplektid - virtuaalmasinate loomine, kustutamine, muutmine, varundamine. Neid torujuhtmeid kasutati kasutuselevõtuprotsessi esimese etapina.
Tulemuseks on see, et tarnitud seadmed ei vasta panga jõudluse ja veataluvuse nõuetele. Panga DIT otsustas luua Nutanixi tarkvarapaketil põhineva kompleksi.
2 etapp. Võtsime defineeritud pinu ja kirjutasime kõigi alamsüsteemide jaoks automatiseeritud installi- ja konfigureerimisjärgsed skriptid, nii et kõik viidi pilootprogrammist sihtahelasse üle võimalikult kiiresti. Kõik süsteemid võeti kasutusele tõrketaluvusega konfiguratsioonis (kus seda võimalust ei piira tarnija litsentsipoliitikad) ning need olid ühendatud mõõdikute ja sündmuste kogumise alamsüsteemidega. IB analüüsis oma nõuete täitmist ja andis rohelise tule.
3 etapp. Kõigi alamsüsteemide ja nende sätete migreerimine uude PAC-i. Infrastruktuuri automatiseerimise skriptid kirjutati ümber ja DSO alamsüsteemide migreerimine viidi lõpule täisautomaatses režiimis. IP arenduse kontuurid taastati arendusmeeskondade torustike abil.
Samm 4. Rakendustarkvara installimise automatiseerimine. Need ülesanded püstitasid uute meeskondade meeskonnajuhid.
Samm 5. Kasutamine.
Kaugjuurdepääs
Arendusmeeskonnad palusid vooluringiga töötamisel maksimaalset paindlikkust ning kaugjuurdepääsu nõue isiklikest sülearvutitest tõstatati juba projekti alguses. Pangal oli juba kaugjuurdepääs, kuid see ei sobinud arendajatele. Fakt on see, et skeem kasutas kasutaja ühendust kaitstud VDI-ga. See sobis neile, kes vajasid töökohal vaid posti ja kontoripaketti. Arendajad vajaksid suuri kliente, suure jõudlusega ja palju ressursse. Ja loomulikult pidid need olema staatilised, kuna kasutajaseansi kadumine neile, kes töötavad näiteks VStudio või muu SDK-ga, on vastuvõetamatu. Suure hulga paksude staatiliste VDI-de korraldamine kõikidele arendusmeeskondadele suurendas oluliselt olemasoleva VDI-lahenduse maksumust.
Otsustasime töötada kaugjuurdepääsu nimel otse arendussegmendi ressurssidele. Jira, Wiki, Gitlab, Nexus, ehitage ja katsetage pingid, virtuaalne infrastruktuur. Turvatöötajad on nõudnud juurdepääsu võimaldamist ainult järgmistel juhtudel:
- Pangas juba olemasolevate tehnoloogiate kasutamine.
- Taristu ei tohiks kasutada olemasolevaid domeenikontrollereid, mis salvestavad produktiivsete kontoobjektide kirjeid.
- Juurdepääs peaks olema piiratud ainult nende ressurssidega, mida konkreetne meeskond vajab (et üks tootemeeskond ei pääseks juurde teise meeskonna ressurssidele).
- Maksimaalne kontroll RBAC üle süsteemides.
Selle tulemusena loodi selle segmendi jaoks eraldi domeen. See domeen sisaldas kõiki arendussegmendi ressursse, nii kasutaja mandaate kui ka infrastruktuuri. Selle domeeni kirjete elutsüklit hallatakse pangas olemasoleva IdM-i abil.
Otsene kaugjuurdepääs korraldati panga olemasoleva varustuse alusel. Juurdepääsukontroll jaotati AD-rühmadeks, millele vastasid kontekstireeglid (üks tooterühm = üks reeglite rühm).
VM-i mallihaldus
Montaaži- ja testimistsükli loomise kiirus on üks peamisi arendusüksuse juhi seatud KPI-sid, sest keskkonna ettevalmistamise kiirus mõjutab otseselt konveieri üldist täitmisaega. VM-i baaspiltide ettevalmistamiseks kaaluti kahte võimalust. Esimene on minimaalsed kujutise suurused, vaikimisi kõikidele süsteemitoodetele, maksimaalne vastavus panga sätetele. Teine on baaspilt, mis sisaldab paigaldatud raskeveokite POPPO-d, mille paigaldusaeg võib oluliselt mõjutada torujuhtme täitmiskiirust.
Arendusel võeti arvesse ka infrastruktuuri ja turvanõudeid - piltide ajakohasena hoidmine (plaastrid jne), integreerimine SIEM-iga, turvaseaded vastavalt pangastandarditele.
Selle tulemusena otsustati kasutada minimaalselt pilte, et minimeerida nende ajakohasena hoidmise kulusid. Põhi-OS-i värskendamine on palju lihtsam kui iga pildi paikamine POPPO uute versioonide jaoks.
Tulemuste põhjal koostati nimekiri minimaalsest nõutavast operatsioonisüsteemide komplektist, mille uuendamise viib läbi operatsioonide meeskond ning konveieri skriptid vastutavad täielikult tarkvara uuendamise ja vajadusel versiooni muutmise eest. installitud tarkvarast – lihtsalt kandke vajalik silt torujuhtmele. Jah, see nõuab devopsi tootemeeskonnal keerukamaid juurutusstsenaariume, kuid see vähendab oluliselt põhipiltide toetamiseks vajalikku tööaega, mille hooldamiseks võib muidu vaja minna üle saja põhilise VM-pildi.
Interneti-ühendus
Teiseks komistuskiviks pangandusturvalisuse juures oli ligipääs internetiressurssidele arenduskeskkonnast. Lisaks võib selle juurdepääsu jagada kahte kategooriasse:
- Infrastruktuuri juurdepääs.
- Arendaja juurdepääs.
Juurdepääs infrastruktuurile korraldati väliste hoidlate puhverserveriga Nexusega. See tähendab, et otsest juurdepääsu virtuaalmasinatest ei pakutud. See võimaldas jõuda kompromissini infoturbe osas, mis oli kategooriliselt vastu igasuguse juurdepääsu võimaldamisele arendussegmendist välismaailmale.
Arendajad vajasid arusaadavatel põhjustel juurdepääsu Internetile (stackoverflow). Ja kuigi kõikidel käskudel, nagu eespool mainitud, oli vooluringile kaugjuurdepääs, pole see alati mugav, kui te ei saa IDE-s olevas pangas arendaja töökohalt klahve ctrl+v teha.
IS-iga saavutati kokkulepe, et esialgu, testimisetapis, võimaldatakse juurdepääs pangapuhverserveri kaudu valge nimekirja alusel. Projekti lõppedes kantakse juurdepääs musta nimekirja. Koostati suured juurdepääsutabelid, mis näitasid peamised ressursid ja hoidlad, millele projekti alguses juurdepääsu oli vaja. Nende juurdepääsude kooskõlastamine võttis üsna palju aega, mis võimaldas nõuda võimalikult kiiret üleminekut mustadele nimekirjadele.
Järeldused
Projekt lõppes veidi vähem kui aasta tagasi. Kummalisel kombel läksid kõik töövõtjad õigel ajal üle uuele virnale ja uue automaatika tõttu ei lahkunud keegi. IB ei kiirusta positiivset tagasisidet jagama, kuid ei kurda ka, millest võib järeldada, et neile meeldib. Konfliktid on vaibunud, sest infoturve tunneb end taas kontrolli all, kuid ei sega arendusprotsesse. Meeskondadele anti rohkem vastutust ning üldine suhtumine infoturbesse muutus paremaks. Pank mõistis, et üleminek DevSecOpsile oli peaaegu vältimatu, ja tegi seda minu arvates kõige õrnemalt ja õigemalt.
Aleksander Šubin, süsteemiarhitekt.
Allikas: www.habr.com