Pankki ulkoistaa projektinsa useille urakoitsijoille. "Ulkoiset" kirjoittavat koodin ja lähettävät sitten tulokset ei kovin kätevässä muodossa. Tarkemmin sanottuna prosessi näytti tältä: he luovuttivat projektin, joka läpäisi toiminnalliset testit heidän kanssaan, ja sen jälkeen testattiin pankkialueen sisällä integraatiota, kuormitusta ja niin edelleen. Usein havaittiin, että testit epäonnistuivat. Sitten kaikki palasi ulkoiselle kehittäjälle. Kuten arvata saattaa, tämä merkitsi pitkiä läpimenoaikoja virheenkorjauksille.
Pankki päätti, että on mahdollista ja tarpeellista vetää koko putki siipiensä alle sitoumuksista vapauttamiseen. Jotta kaikki olisi yhtenäistä ja tuotteesta vastaavien tiimien hallinnassa pankissa. Eli ikään kuin ulkopuolinen urakoitsija olisi vain työskennellyt jossain toimiston viereisessä huoneessa. Yrityksen pinossa. Tämä on tavallinen devops.
Mistä Sec tuli? Pankin turvallisuus on asettanut korkeat vaatimukset sille, miten ulkopuolinen urakoitsija voi toimia verkkosegmentissä, mikä pääsy jollakin on, miten ja kuka koodin kanssa työskentelee. IB ei vain vielä tiennyt, että kun urakoitsijat työskentelevät ulkona, pankkistandardeja noudatetaan harvoja. Ja sitten parin päivän kuluttua kaikkien on alettava tarkkailla niitä.
Yksinkertainen paljastus siitä, että urakoitsijalla oli täysi pääsy tuotekoodiin, oli jo kääntänyt heidän maailmansa ylösalaisin.
Tällä hetkellä DevSecOpsin tarina alkoi, josta haluan kertoa teille.
Mitä käytännön johtopäätöksiä pankki teki tilanteesta?
Siitä, että kaikki tehdään väärin, oli paljon kiistaa. Kehittäjät sanoivat, että turvallisuus on vain kiireinen yrittäessään häiritä kehitystä, ja he yrittävät, kuten vartijat, kieltää ajattelematta. Tietoturvaasiantuntijat puolestaan epäröivät valita näkökulmien välillä: "kehittäjät luovat haavoittuvuuksia piiriimme" ja "kehittäjät eivät luo haavoittuvuuksia, vaan ovat niitä itse". Kiista olisi jatkunut pitkään, ellei uusia markkinavaatimuksia ja DevSecOps-paradigman ilmaantumista olisi syntynyt. Oli mahdollista selittää, että juuri tämä prosessien automatisointi tietoturvavaatimukset huomioon ottaen "pakkauksesta" auttaa kaikkia pysymään onnellisina. Siinä mielessä, että säännöt kirjoitetaan heti ylös eivätkä muutu pelin aikana (tietoturva ei estä mitään odottamatta), ja kehittäjät pitävät tietoturvan ajan tasalla kaikesta, mitä tapahtuu (tietoturva ei kohtaa jotain yhtäkkiä) . Jokainen joukkue on myös vastuussa äärimmäisestä turvallisuudesta, ei jotkin abstraktit vanhemmat veljet.
- Koska ulkopuolisilla työntekijöillä on jo pääsy koodiin ja useisiin sisäisiin järjestelmiin, on todennäköisesti mahdollista poistaa asiakirjoista vaatimus "kehittäminen on tehtävä kokonaan pankin infrastruktuurilla".
- Toisaalta meidän on vahvistettava tapahtumien hallintaa.
- Kompromissi oli monitoimitiimien luominen, joissa työntekijät työskentelevät tiiviisti ulkopuolisten ihmisten kanssa. Tässä tapauksessa sinun on varmistettava, että tiimi työskentelee pankin palvelimilla olevilla työkaluilla. Alusta loppuun.
Eli urakoitsijat voidaan päästää sisään, mutta heille on annettava erilliset segmentit. Että he eivät tuo ulkopuolelta minkäänlaista tartuntaa pankin infrastruktuuriin ja etteivät näkisi enempää kuin on tarpeellista. No niin, että heidän toimintansa kirjataan. DLP suojaa vuotoja vastaan, kaikki tämä oli mukana.
Periaatteessa kaikki pankit tulevat tähän ennemmin tai myöhemmin. Tässä mentiin vauhdilla ja sovittiin vaatimukset sellaisille ympäristöille, joissa "ulkoiset" toimivat. Siellä ilmestyi suurin valikoima kulunvalvontatyökaluja, haavoittuvuuden tarkistustyökaluja, viruksentorjuntaanalyysejä piireissä, kokoonpanoissa ja testeissä. Tätä kutsutaan DevSecOpsiksi.
Yhtäkkiä kävi selväksi, että jos ennen DevSecOpsia pankkiturvallisuus ei voinut hallita sitä, mitä kehittäjän puolella tapahtuu, niin uudessa paradigmassa turvallisuutta ohjataan samalla tavalla kuin tavallisia infrastruktuurin tapahtumia. Vasta nyt on hälytyksiä kokoonpanoista, kirjastojen hallinnasta ja niin edelleen.
Jäljelle jää vain joukkueiden siirtäminen uuteen malliin. No, luo infrastruktuuri. Mutta nämä ovat pieniä asioita, se on kuin pöllön piirtämistä. Itse asiassa auttoimme infrastruktuurin kanssa, ja tuolloin kehitysprosessit olivat muuttumassa.
Mikä on muuttunut
Päätimme toteuttaa sen pienin askelin, koska ymmärsimme, että monet prosessit hajoavat ja monet "ulkopuoliset" eivät ehkä kestä uusia työoloja kaikkien valvonnassa.
Aluksi loimme poikkitoiminnallisia tiimejä ja opimme organisoimaan projekteja uudet vaatimukset huomioiden. Organisatorisessa mielessä keskustelimme siitä, mitä prosesseja. Tuloksena oli kaavio kokoonpanoputkistosta kaikkien vastuuhenkilöiden kanssa.
- CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Testi: Sonarqube, SoapUI, jMeter, Seleeni: MF Fortify, Performance Center, MF UFT, Ataccama.
- esittely (raportointi, viestintä): Grafana, Kibana, Jira, Confluence, RocketChat.
- Operations (huolto, hallinta): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Valittu pino:
- Tietokanta - Atlassian Confluence;
- Tehtävien seuranta - Atlassian Jira;
- Artefakttien arkisto - "Nexus";
- Jatkuva integrointijärjestelmä - "Gitlab CI";
- Jatkuva analyysijärjestelmä - "SonarQube";
- Sovellusturvallisuusanalyysijärjestelmä - "Micro Focus Fortify";
- Viestintäjärjestelmä - "GitLab Mattermost";
- Kokoonpanon hallintajärjestelmä - "Mahdollisuus";
- Valvontajärjestelmä - "ELK", "TICK Stack" ("InfluxData").
He alkoivat luoda tiimiä, joka olisi valmis vetämään urakoitsijoita sisään. Ymmärretään, että on olemassa useita tärkeitä asioita:
- Kaiken pitäisi olla yhtenäistä, ainakin koodia siirrettäessä. Koska urakoitsijoita oli yhtä monta kuin erilaisia kehitysprosesseja, joilla on omat erityispiirteensä. Kaikki piti sovittaa suunnilleen yhteen, mutta vaihtoehtoja.
- Urakoitsijoita on monia, eikä infrastruktuurin luominen manuaalisesti sovi. Kaikkien uusien tehtävien tulisi alkaa hyvin nopeasti – eli ilmentymä tulisi ottaa käyttöön lähes välittömästi, jotta kehittäjillä on joukko ratkaisuja putkilinjansa hallintaan.
Ensimmäisen askeleen ottamiseksi oli välttämätöntä ymmärtää, mitä oli tehty. Ja meidän piti päättää, miten sinne päästään. Aloitimme auttamalla piirtämään kohderatkaisun arkkitehtuuria sekä infrastruktuurissa että CI/CD-automaatiossa. Sitten aloimme kokoamaan tätä kuljetinta. Tarvitsimme yhden infrastruktuurin, saman kaikille, jossa samat kuljettimet kulkisivat. Tarjosimme vaihtoehtoja laskelmilla, pankki ajatteli ja päätti sitten mitä rakennetaan ja millä varoilla.
Seuraava on piirin luominen - ohjelmiston asennus, konfigurointi. Skriptien kehittäminen infrastruktuurin käyttöönottoa ja hallintaa varten. Seuraavaksi tulee siirtyminen kuljetintukeen.
Päätimme testata kaikkea pilotissa. Mielenkiintoista on, että pilotoinnin aikana tietty pino ilmestyi pankkiin ensimmäistä kertaa. Pilotin piiriin tarjottiin muun muassa kotimaista toimittajaa yhdelle ratkaisulle nopeaa lanseerausta varten. Turvallisuus tutustui häneen lentäjän aikana, ja se jätti unohtumattoman vaikutuksen. Kun päätimme vaihtaa, onneksi infrastruktuurikerros korvattiin Nutanix-ratkaisulla, joka oli jo pankissa. Lisäksi ennen sitä se oli VDI:lle, mutta käytimme sitä uudelleen infrastruktuuripalveluihin. Pienillä määrillä se ei sopinut talouteen, mutta suurilla volyymeilla siitä tuli erinomainen kehitys- ja testausympäristö.
Loput pinosta ovat enemmän tai vähemmän tuttuja kaikille. Käytössä oli Ansiblen automaatiotyökaluja, joiden kanssa tietoturvaasiantuntijat tekivät tiivistä yhteistyötä. Atlassin-pino oli pankin käytössä ennen projektia. Fortinet-tietoturvatyökalut - sen ovat ehdottaneet turvallisuushenkilöt itse. Pankki on luonut testauskehyksen, ei kysymyksiä. Arkistojärjestelmä herätti kysymyksiä, siihen piti tottua.
Urakoitsijat saivat uuden pinon. He antoivat meille aikaa kirjoittaa se uudelleen GitlabCI:lle ja siirtää Jira pankkisektoriin ja niin edelleen.
askel askeleelta
Vaihe 1. Ensin käytimme kotimaisen toimittajan ratkaisua, tuote yhdistettiin uuteen luotuun DSO-verkkosegmenttiin. Alusta valittiin sen toimitusajan, skaalausjoustavuuden ja täyden automaation mahdollisuuden vuoksi. Suoritetut testit:
- Mahdollisuus virtualisointialustan infrastruktuurin (verkko, levyalijärjestelmä, laskentaresurssialijärjestelmä) joustavaan ja täysin automatisoituun hallintaan.
- Virtuaalikoneen elinkaaren hallinnan automatisointi (mallinnus, tilannevedokset, varmuuskopiot).
Asennuksen ja alustan peruskonfiguroinnin jälkeen sitä käytettiin toisen vaiheen alijärjestelmien (DSO-työkalut, vähittäiskaupan järjestelmien kehityslinjaukset) sijoituspaikkana. Tarvittavat putkisarjat luotiin - virtuaalikoneiden luominen, poistaminen, muokkaaminen, varmuuskopiointi. Näitä putkia käytettiin käyttöönottoprosessin ensimmäisenä vaiheena.
Seurauksena on, että toimitetut laitteet eivät täytä pankin suorituskyky- ja vikasietovaatimuksia. Pankin DIT päätti luoda Nutanix-ohjelmistopakettiin perustuvan kokonaisuuden.
Vaihe 2. Otimme määritellyn pinon ja kirjoitimme automaattiset asennus- ja konfiguroinnin jälkeiset skriptit kaikille alijärjestelmille, jotta kaikki siirrettiin pilotista kohdepiiriin mahdollisimman nopeasti. Kaikki järjestelmät otettiin käyttöön vikasietoisessa kokoonpanossa (jossa tätä ominaisuutta eivät rajoita toimittajan lisenssikäytännöt) ja ne yhdistettiin mittareihin ja tapahtumien keruualijärjestelmiin. IB analysoi vaatimustensa noudattamisen ja näytti vihreää valoa.
Vaihe 3. Kaikkien alijärjestelmien ja niiden asetusten siirto uuteen PAC:iin. Infrastruktuurin automaatiokomentosarjat kirjoitettiin uudelleen ja DSO-alijärjestelmien migraatio suoritettiin täysin automatisoidussa tilassa. IP-kehityksen ääriviivat luotiin uudelleen kehitystiimien putkien avulla.
Vaihe 4. Sovellusohjelmistojen asennuksen automatisointi. Nämä tehtävät asettivat uusien ryhmien tiiminjohtajat.
Vaihe 5. hyväksikäyttö.
Etäyhteys
Kehitystiimit vaativat maksimaalista joustavuutta piirin kanssa työskentelyyn, ja vaatimus etäkäytöstä henkilökohtaisista kannettavista tietokoneista nostettiin jo projektin alussa. Pankilla oli jo etäkäyttö, mutta se ei sovellu kehittäjille. Tosiasia on, että järjestelmä käytti käyttäjän yhteyttä suojattuun VDI:hen. Tämä sopi niille, jotka tarvitsivat työpaikallaan vain postia ja toimistopakettia. Kehittäjät tarvitsisivat raskaita asiakkaita, korkeaa suorituskykyä ja paljon resursseja. Ja tietysti niiden oli oltava staattisia, koska käyttäjäistunnon menettämistä ei voida hyväksyä niille, jotka työskentelevät esimerkiksi VStudion tai muun SDK:n kanssa. Suuren määrän paksujen staattisten VDI:iden järjestäminen kaikille kehitystiimeille nosti huomattavasti nykyisen VDI-ratkaisun kustannuksia.
Päätimme kehittää etäkäyttöä suoraan kehityssegmentin resursseihin. Jira, Wiki, Gitlab, Nexus, rakentaa ja testata penkkejä, virtuaalinen infrastruktuuri. Vartijat ovat vaatineet, että pääsy voidaan tarjota vain seuraavin edellytyksin:
- Pankissa jo saatavilla olevien teknologioiden käyttö.
- Infrastruktuuri ei saa käyttää olemassa olevia toimialueen ohjaimia, jotka tallentavat tuottavien tiliobjektien tietueita.
- Pääsy tulee rajoittaa vain tietyn tiimin tarvitsemiin resursseihin (joten yksi tuotetiimi ei voi käyttää toisen tiimin resursseja).
- Maksimaalinen RBAC-hallinta järjestelmissä.
Tämän seurauksena tälle segmentille luotiin erillinen verkkotunnus. Tämä verkkotunnus sisälsi kaikki kehityssegmentin resurssit, sekä käyttäjätiedot että infrastruktuurin. Tämän verkkotunnuksen tietueiden elinkaarta hallitaan pankissa olemassa olevan IdM:n avulla.
Suora etäyhteys järjestettiin pankin olemassa olevien laitteiden pohjalta. Kulunvalvonta jaettiin AD-ryhmiin, joihin vastasi kontekstisäännöt (yksi tuoteryhmä = yksi sääntöryhmä).
VM-mallien hallinta
Kokoonpano- ja testaussilmukan luomisen nopeus on yksi tärkeimmistä kehitysyksikön päällikön asettamista KPI:istä, koska ympäristön valmistelun nopeus vaikuttaa suoraan putkilinjan kokonaissuoritusaikaan. Pohdittiin kahta vaihtoehtoa VM-peruskuvien valmisteluun. Ensimmäinen on vähimmäiskuvakoot, oletusarvo kaikille järjestelmätuotteille, maksimaalinen noudattaminen pankin asetuksiin liittyvien käytäntöjen kanssa. Toinen on peruskuva, joka sisältää raskaan POPPO:n asennettuna, jonka asennusaika voi vaikuttaa suuresti putkilinjan suoritusnopeuteen.
Myös infrastruktuuri- ja turvallisuusvaatimukset otettiin huomioon kehitystyössä - kuvien pitäminen ajan tasalla (korjaukset jne.), integrointi SIEM:iin, suojausasetukset pankkien standardien mukaan.
Tämän seurauksena päätettiin käyttää mahdollisimman vähän kuvia niiden ajan tasalla pitämisestä aiheutuvien kustannusten minimoimiseksi. Peruskäyttöjärjestelmän päivittäminen on paljon helpompaa kuin jokaisen kuvan korjaaminen uusille POPPO-versioille.
Tulosten perusteella muodostettiin lista vaadittavasta käyttöjärjestelmien vähimmäisjoukosta, jonka päivityksen suorittaa operaatiotiimi ja putkistosta tulevat komentosarjat ovat täysin vastuussa ohjelmiston päivityksestä ja tarvittaessa version muuttamisesta. asennetusta ohjelmistosta - siirrä vain tarvittava tunniste putkistoon. Kyllä, tämä edellyttää, että devops-tuotetiimillä on monimutkaisempia käyttöönottoskenaarioita, mutta se lyhentää huomattavasti peruskuvien tukemiseen tarvittavaa toiminta-aikaa, jonka ylläpito saattaisi muuten vaatia yli sadan virtuaalikoneen peruskuvan ylläpitoon.
Internet-yhteys
Toinen pankkiturvallisuuden kompastuskivi oli pääsy Internet-resursseihin kehitysympäristöstä. Lisäksi tämä käyttöoikeus voidaan jakaa kahteen luokkaan:
- Pääsy infrastruktuuriin.
- Kehittäjän pääsy.
Infrastruktuurin käyttö järjestettiin välityspalvelimella ulkoisia tietovarastoja Nexuksen kanssa. Toisin sanoen suoraa pääsyä virtuaalikoneita ei tarjottu. Tämä mahdollisti kompromissin tietoturvan kanssa, joka vastusti jyrkästi kehityssegmentin pääsyä ulkomaailmaan.
Kehittäjät tarvitsivat pääsyä Internetiin ilmeisistä syistä (stackoverflow). Ja vaikka kaikilla komennoilla, kuten edellä mainittiin, oli etäkäyttö piiriin, se ei ole aina kätevää, kun et voi tehdä ctrl+v:tä kehittäjän työpaikalta IDE:n pankissa.
IS:n kanssa sovittiin, että aluksi, testausvaiheessa, pääsy tarjotaan pankin välityspalvelimen kautta valkoisen listan perusteella. Projektin päätyttyä pääsy siirtyy mustalle listalle. Valmisteltiin valtavat pääsytaulukot, joista käy ilmi tärkeimmät resurssit ja tietovarastot, joihin pääsy vaadittiin projektin alussa. Näiden pääsyjen koordinointi vei melko paljon aikaa, mikä mahdollisti nopeimman mahdollisen siirtymisen mustille listoille.
Tulokset
Projekti päättyi hieman alle vuosi sitten. Kummallista kyllä, kaikki urakoitsijat siirtyivät uuteen pinoon ajallaan, eikä kukaan lähtenyt uuden automaation takia. IB:llä ei ole kiirettä jakaa positiivista palautetta, mutta ei myöskään valittaa, josta voimme päätellä, että he pitävät siitä. Konfliktit ovat laantuneet, koska tietoturva tuntuu taas olevan hallinnassa, mutta ei häiritse kehitysprosesseja. Ryhmät saivat enemmän vastuuta ja yleinen asenne tietoturvaan parani. Pankki ymmärsi, että DevSecOpsiin siirtyminen oli lähes väistämätöntä, ja teki sen mielestäni lempeimmällä ja oikealla tavalla.
Alexander Shubin, järjestelmäarkkitehti.
Lähde: will.com