Banka zadáva svoje projekty mnohým dodávateľom. „Externé osoby“ napíšu kód a potom prenesú výsledky v nie príliš vhodnej forme. Konkrétne proces vyzeral takto: odovzdali projekt, ktorý s nimi prešiel funkčnými testami, a potom bol testovaný vo vnútri bankového perimetra na integráciu, zaťaženie atď. Často sa zistilo, že testy zlyhali. Potom sa všetko vrátilo k externému vývojárovi. Ako môžete hádať, znamenalo to dlhé dodacie lehoty na opravy chýb.
Banka sa rozhodla, že je možné a potrebné pretiahnuť pod svoje krídla celý plynovod, od záväzkov až po uvoľnenie. Aby bolo všetko jednotné a pod kontrolou tímov zodpovedných za produkt v banke. To znamená, ako keby externý dodávateľ jednoducho pracoval niekde vo vedľajšej miestnosti kancelárie. Na firemnom zásobníku. Toto je obyčajný devops.
Odkiaľ pochádza Sec? Bezpečnosť banky kládla vysoké nároky na to, ako môže externý dodávateľ fungovať v segmente siete, aký má kto prístup, ako a kto pracuje s kódom. Ide len o to, že IB ešte nevedela, že keď dodávatelia pracujú vonku, dodržiava sa len málo bankových štandardov. A potom ich o pár dní musí začať každý pozorovať.
Jednoduché odhalenie, že dodávateľ mal plný prístup ku kódu produktu, už obrátilo ich svet hore nohami.
V tejto chvíli sa začal príbeh DevSecOps, o ktorom vám chcem porozprávať.
Aké praktické závery banka z tejto situácie vyvodila?
Veľa sa polemizovalo o tom, že všetko sa robí zlým spôsobom. Vývojári povedali, že bezpečnosť je zaneprázdnená len snahou zasahovať do vývoja a oni, ako strážcovia, sa snažia bez rozmýšľania zakázať. Na druhej strane bezpečnostní špecialisti váhali medzi výberom z hľadísk: „vývojári vytvárajú zraniteľné miesta v našom okruhu“ a „vývojári nevytvárajú zraniteľné miesta, ale sú nimi sami“. Spor by pokračoval ešte dlho, nebyť nových požiadaviek trhu a objavenia sa paradigmy DevSecOps. Bolo možné vysvetliť, že práve táto automatizácia procesov zohľadňujúca požiadavky informačnej bezpečnosti „out of the box“ pomôže každému zostať šťastným. V tom zmysle, že pravidlá sú spísané okamžite a počas hry sa nemenia (informačná bezpečnosť nezakáže niečo neočakávane) a vývojári informujú informačnú bezpečnosť o všetkom, čo sa stane (informačná bezpečnosť sa s niečím nestretne náhle) . Každý tím je tiež zodpovedný za maximálnu bezpečnosť a nie niektorí abstraktní starší bratia.
- Keďže externí zamestnanci už majú prístup ku kódu a množstvu interných systémov, je pravdepodobne možné z dokumentov odstrániť požiadavku „vývoj musí prebiehať výlučne na infraštruktúre banky“.
- Na druhej strane musíme posilniť kontrolu nad tým, čo sa deje.
- Kompromisom bolo vytvorenie medzifunkčných tímov, kde zamestnanci úzko spolupracujú s externými ľuďmi. V tomto prípade sa musíte uistiť, že tím pracuje na nástrojoch na serveroch banky. Od začiatku až do konca.
To znamená, že dodávateľov je možné povoliť, ale je potrebné im prideliť samostatné segmenty. Aby do infraštruktúry banky nepriniesli nejakú infekciu zvonku a nevideli viac, ako je potrebné. No, aby boli ich akcie zaznamenané. DLP na ochranu proti úniku, toto všetko bolo zahrnuté.
V zásade na to skôr či neskôr prídu všetky banky. Tu sme sa vydali po vychodených cestách a dohodli sme sa na požiadavkách na také prostredia, kde fungujú „externí“. Objavil sa maximálny rozsah nástrojov na kontrolu prístupu, nástrojov na kontrolu zraniteľnosti, antivírusovej analýzy na obvodoch, zostavách a testoch. Toto sa nazýva DevSecOps.
Zrazu sa ukázalo, že ak pred DevSecOps banková bezpečnosť nemala kontrolu nad tým, čo sa deje na strane vývojára, tak v novej paradigme je bezpečnosť kontrolovaná rovnakým spôsobom ako bežné udalosti v infraštruktúre. Len teraz sú upozornenia na zhromaždenia, kontrola knižníc atď.
Zostáva už len preniesť tímy do nového modelu. No, vytvorte infraštruktúru. Ale to sú maličkosti, je to ako kresliť sovu. Vlastne sme pomáhali s infraštruktúrou a v tom čase sa menili vývojové procesy.
Čo sa zmenilo
Rozhodli sme sa to implementovať po malých krokoch, pretože sme pochopili, že veľa procesov sa rozpadne a mnohí „externí“ nemusia nové pracovné podmienky pod dohľadom všetkých vydržať.
Najprv sme vytvorili medzifunkčné tímy a naučili sme sa organizovať projekty s prihliadnutím na nové požiadavky. V zmysle organizačne sme diskutovali o akých procesoch. Výsledkom bola schéma montážneho potrubia so všetkými zodpovednými.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Test: Sonarqube, SoapUI, jMeter, Selén: MF Fortify, Performance Center, MF UFT, Ataccama.
- Predstavenie (správy, komunikácia): Grafana, Kibana, Jira, Confluence, RocketChat.
- operácie (údržba, správa): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Vybraný zásobník:
- Knowledge Base - Atlassian Confluence;
- Sledovač úloh - Atlassian Jira;
- Úložisko artefaktov - „Nexus“;
- Systém kontinuálnej integrácie – „Gitlab CI“;
- Systém kontinuálnej analýzy - „SonarQube“;
- Systém analýzy bezpečnosti aplikácií - „Micro Focus Fortify“;
- Komunikačný systém – „GitLab Mattermost“;
- Systém riadenia konfigurácie - „Ansible“;
- Monitorovací systém - „ELK“, „TICK Stack“ („InfluxData“).
Začali vytvárať tím, ktorý by bol pripravený ťahať dodávateľov dovnútra. Je zrejmé, že existuje niekoľko dôležitých vecí:
- Všetko by malo byť zjednotené, aspoň pri prenose kódu. Pretože tam bolo toľko dodávateľov, koľko bolo toľko rôznych vývojových procesov s vlastnými zvláštnosťami. Bolo potrebné zmestiť každého približne do jedného, no s možnosťami.
- Existuje veľa dodávateľov a manuálne vytváranie infraštruktúry nie je vhodné. Akákoľvek nová úloha by mala začať veľmi rýchlo – to znamená, že inštancia by mala byť nasadená takmer okamžite, aby vývojári mali k dispozícii sadu riešení na správu ich potrubia.
Aby sme urobili prvý krok, bolo potrebné pochopiť, čo sa robí. A museli sme určiť, ako sa tam dostaneme. Začali sme tým, že sme pomohli nakresliť architektúru cieľového riešenia v oblasti infraštruktúry a automatizácie CI/CD. Potom sme začali s montážou tohto dopravníka. Potrebovali sme jednu infraštruktúru, rovnakú pre všetkých, kde by jazdili rovnaké dopravníky. Ponúkli sme možnosti s kalkuláciami, pomyslela si banka, potom sa rozhodli, čo sa bude stavať a s akými prostriedkami.
Nasleduje vytvorenie okruhu – inštalácia softvéru, konfigurácia. Vývoj skriptov pre nasadenie a správu infraštruktúry. Ďalej nasleduje prechod na podporu dopravníka.
Všetko sme sa rozhodli otestovať na pilote. Zaujímavé je, že počas pilotovania sa v banke prvýkrát objavil istý stack. Okrem iného bol v rámci pilotného projektu ponúknutý domáci predajca jedného z riešení na rýchle spustenie. Ochranka ho spoznala počas pilotovania a zanechalo to nezabudnuteľný dojem. Keď sme sa rozhodli prejsť, našťastie bola infraštruktúrna vrstva nahradená riešením Nutanix, ktoré už bolo v banke predtým. Navyše, predtým to bolo pre VDI, ale znova sme to použili na infraštruktúrne služby. Pri malých objemoch nezapadal do ekonomiky, no pri veľkých objemoch sa stal výborným prostredím pre vývoj a testovanie.
Zvyšok zásobníka je viac-menej každému známy. Boli použité automatizačné nástroje v Ansible, s ktorými úzko spolupracovali bezpečnostní špecialisti. Pred projektom banka používala zásobník Atlassin. Bezpečnostné nástroje Fortinet – navrhli to samotní ľudia z bezpečnosti. Testovací rámec vytvorila banka, bez otázok. Úložný systém vyvolával otázky, musel som si naň zvyknúť.
Dodávatelia dostali nový zásobník. Dali nám čas na prepísanie pre GitlabCI a na migráciu Jira do bankového segmentu atď.
Krok za krokom
Krok 1. Najprv sme použili riešenie od domáceho predajcu, produkt bol napojený na novovytvorený segment siete PDS. Platforma bola zvolená pre jej dodaciu dobu, flexibilitu škálovania a možnosť plnej automatizácie. Vykonané testy:
- Možnosť flexibilnej a plne automatizovanej správy infraštruktúry virtualizačnej platformy (sieť, diskový subsystém, subsystém výpočtových zdrojov).
- Automatizácia správy životného cyklu virtuálnych strojov (šablóny, snímky, zálohy).
Platforma bola po inštalácii a základnej konfigurácii použitá ako miesto umiestnenia subsystémov druhej etapy (nástroje PDS, osnovy rozvoja maloobchodných systémov). Boli vytvorené potrebné sady potrubí - vytváranie, mazanie, modifikácia, zálohovanie virtuálnych strojov. Tieto potrubia boli použité ako prvá fáza procesu nasadenia.
Výsledkom je, že poskytnuté vybavenie nespĺňa požiadavky banky na výkon a odolnosť voči poruchám. DIT banky sa rozhodlo vytvoriť komplex založený na softvérovom balíku Nutanix.
Krok 2. Vzali sme zásobník, ktorý bol definovaný, a napísali sme automatizované inštalačné a post-konfiguračné skripty pre všetky podsystémy, aby sa všetko prenieslo z pilotného do cieľového okruhu čo najrýchlejšie. Všetky systémy boli nasadené v konfigurácii odolnej voči chybám (kde táto schopnosť nie je obmedzená licenčnými politikami dodávateľa) a boli pripojené k podsystémom metrík a zberu udalostí. IB analyzovala dodržiavanie svojich požiadaviek a dala zelenú.
Krok 3. Migrácia všetkých podsystémov a ich nastavení na nový PAC. Boli prepísané skripty automatizácie infraštruktúry a migrácia subsystémov PDS bola dokončená v plne automatizovanom režime. Kontúry vývoja IP boli znovu vytvorené pomocou kanálov vývojových tímov.
Krok 4. Automatizácia inštalácie aplikačného softvéru. Tieto úlohy stanovili vedúci nových tímov.
Krok 5. Vykorisťovanie.
Vzdialený prístup
Vývojové tímy žiadali maximálnu flexibilitu pri práci s okruhom a hneď na začiatku projektu bola vznesená požiadavka na vzdialený prístup z osobných notebookov. Banka už mala vzdialený prístup, ale ten nebol vhodný pre developerov. Faktom je, že schéma využívala pripojenie používateľa k chránenému VDI. To bolo vhodné pre tých, ktorí na svojom pracovisku potrebovali iba poštu a kancelársky balík. Vývojári by potrebovali náročných klientov, vysoký výkon, s množstvom zdrojov. A samozrejme, museli byť statické, pretože strata používateľskej relácie pre tých, ktorí pracujú s VStudio (napríklad) alebo iným SDK, je neprijateľná. Organizácia veľkého počtu hrubých statických VDI pre všetky vývojové tímy výrazne zvýšila náklady na existujúce riešenie VDI.
Rozhodli sme sa pracovať na vzdialenom prístupe priamo k zdrojom vývojového segmentu. Jira, Wiki, Gitlab, Nexus, budovanie a testovanie lavičiek, virtuálna infraštruktúra. Bezpečnostná služba požadovala, aby bol prístup poskytnutý len za nasledujúcich podmienok:
- Využívať technológie, ktoré sú v banke už dostupné.
- Infraštruktúra by nemala používať existujúce radiče domény, ktoré ukladajú záznamy o produktívnych objektoch účtov.
- Prístup by mal byť obmedzený len na zdroje, ktoré vyžaduje konkrétny tím (takže jeden produktový tím nemôže pristupovať k zdrojom iného tímu).
- Maximálna kontrola nad RBAC v systémoch.
V dôsledku toho bola pre tento segment vytvorená samostatná doména. V tejto doméne sa nachádzali všetky prostriedky segmentu vývoja, používateľské poverenia aj infraštruktúra. Životný cyklus záznamov v tejto doméne je riadený pomocou IdM existujúceho v banke.
Priamy vzdialený prístup bol organizovaný na základe existujúceho vybavenia banky. Riadenie prístupu bolo rozdelené do AD skupín, ktorým zodpovedali pravidlá o kontextoch (jedna skupina produktov = jedna skupina pravidiel).
Správa šablón VM
Rýchlosť vytvárania montážnej a testovacej slučky je jedným z hlavných KPI, ktoré nastavuje vedúci vývojovej jednotky, pretože rýchlosť prípravy prostredia priamo ovplyvňuje celkový čas realizácie pipeline. Zvažovali sa dve možnosti prípravy základných obrazov virtuálnych počítačov. Prvým je minimálna veľkosť obrázkov, predvolená pre všetky systémové produkty, maximálny súlad s pravidlami banky týkajúcimi sa nastavení. Druhým je základný obrázok, ktorý obsahuje nainštalované vysokovýkonné POPPO, ktorého čas inštalácie môže výrazne ovplyvniť rýchlosť vykonávania potrubia.
Pri vývoji boli zohľadnené aj požiadavky na infraštruktúru a bezpečnosť – udržiavanie aktuálnych obrázkov (záplaty a pod.), integrácia so SIEM, bezpečnostné nastavenia podľa bankových štandardov.
V dôsledku toho bolo rozhodnuté použiť minimálny počet obrázkov, aby sa minimalizovali náklady na ich aktualizáciu. Je oveľa jednoduchšie aktualizovať základný OS ako opravovať každý obrázok pre nové verzie POPPO.
Na základe výsledkov bol vytvorený zoznam minimálnej požadovanej sady operačných systémov, ktorých aktualizáciu vykonáva operačný tím a skripty z potrubia sú plne zodpovedné za aktualizáciu softvéru a v prípade potreby za zmenu verzie. nainštalovaného softvéru - stačí preniesť požadovaný tag do potrubia. Áno, vyžaduje si to od produktového tímu devops zložitejšie scenáre nasadenia, no výrazne to znižuje prevádzkový čas potrebný na podporu základných obrazov, ktorých údržba by inak mohla vyžadovať viac ako sto základných obrazov virtuálnych počítačov.
Prístup na internet
Ďalším kameňom úrazu pri bankovej bezpečnosti bol prístup k internetovým zdrojom z vývojového prostredia. Okrem toho možno tento prístup rozdeliť do dvoch kategórií:
- Prístup k infraštruktúre.
- Prístup vývojára.
Prístup k infraštruktúre bol organizovaný prostredníctvom proxy externých úložísk so zariadením Nexus. To znamená, že priamy prístup z virtuálnych strojov nebol poskytnutý. To umožnilo dosiahnuť kompromis s informačnou bezpečnosťou, ktorá bola kategoricky proti poskytovaniu akéhokoľvek prístupu do vonkajšieho sveta z vývojového segmentu.
Vývojári potrebovali prístup na internet z pochopiteľných dôvodov (stackoverflow). A hoci všetky príkazy, ako je uvedené vyššie, mali vzdialený prístup k okruhu, nie je to vždy vhodné, keď nemôžete urobiť ctrl+v z pracoviska vývojára v banke v IDE.
S IS bola dosiahnutá dohoda, že spočiatku, v štádiu testovania, bude prístup poskytovaný prostredníctvom bankového proxy na základe bieleho zoznamu. Po dokončení projektu sa prístup presunie na čiernu listinu. Boli pripravené obrovské prístupové tabuľky, ktoré uvádzali hlavné zdroje a úložiská, ku ktorým bol potrebný prístup na začiatku projektu. Koordinácia týchto prístupov zabrala pomerne veľa času, čo umožnilo trvať na čo najrýchlejšom prechode na čierne listiny.
výsledky
Projekt skončil o niečo menej ako pred rokom. Napodiv, všetci dodávatelia prešli na nový zásobník včas a nikto neodišiel kvôli novej automatizácii. IB sa s pozitívnou spätnou väzbou neponáhľa, no ani sa nesťažuje, z čoho môžeme usúdiť, že sa im páči. Konflikty ustúpili, pretože informačná bezpečnosť sa opäť cíti pod kontrolou, ale nezasahuje do vývojových procesov. Tímy dostali väčšiu zodpovednosť a celkový prístup k informačnej bezpečnosti sa zlepšil. Banka pochopila, že prechod na DevSecOps je takmer nevyhnutný a urobila to podľa mňa tým najšetrnejším a najsprávnejším spôsobom.
Alexander Shubin, systémový architekt.
Zdroj: hab.com